From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NOR01-OL1-obe.outbound.protection.outlook.com (mail-ol1nor01on2085.outbound.protection.outlook.com [40.107.224.85]) by sourceware.org (Postfix) with ESMTPS id DFB853858C5E for ; Fri, 11 Nov 2022 09:21:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DFB853858C5E Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=westcontrol.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=westcontrol.com ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Wu56zX/0hU+kYRmI24LMDnPLEU6X1SUiK0mjk1ynQy/KwJQmyoXzV0SZjJDFppeeUZh5Ywpz75HSEbQEcDOZjMxRt78nYOXvsbR7CIbb/i9z+ZS4/fMZGnniQpZeisHbe6OtwTYdj5qIRgSe0gAoBCg2Jf7poYgUsxv66mjFM2R1JluKk1TpMn0BuSRcmP4LvivtOYsyuiLpvqgF+B/HGzcPgdv6ZZsJZ35k5ea44VclRwvxgUa24+NW0JHSEpBUr9NXqlUQQBDtVWRskVh/488+ydmfjT/xJqNytGBQkvGUWIMFVuJbYPKlKLY0fdmXQ7jDj+1IxjSyndEKu2CmAw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=wJlHbT598Fsdz8ZPznXOJp1XKPeYwY2TTWwwXTPykTk=; b=bl4SJwB6C6t6O3K5hOuavfObXS3p5vc+FWRdJu49gkg9Y8UhwC5a4rHv95qqS6tguQGQL0+j64oV2vQP95zEVdOEK59qaEBXNXs4haBDeVH8qIL47LDYf4QUbK6hdW6d7DB0Gk5Mf8KA75e44caR3/JXuWRfJLLXAZ9Z5fEV4Sq6GrLiqxrX+Mbv22CPZE0crJPCi+ylcSV7vqSuyL/JQ37gI3Aw4iJMgVnFBPthCmHo0cnpy9toMf0hz3qgn4fpcByOXncaCjGLuiWsVWWk41/IkkmM/AMtGD1r4VZMI0fcQrt70BKjAPU2sW6KWoAN+lT8oyn0LgAaf6zS26LCcA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=westcontrol.com; dmarc=pass action=none header.from=westcontrol.com; dkim=pass header.d=westcontrol.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=westcontrol.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wJlHbT598Fsdz8ZPznXOJp1XKPeYwY2TTWwwXTPykTk=; b=Q5EYw65sj8X1uNFIzSm9MThqEO3w/vCDsEp2XnM5xCQSQDwMRqyv0G4nFXA15AczfnIEC6qx0JuNkqIACTJAAMDxulvaSFw9fdGUppUljOJ5sAKQvul/u+hanSrQz2MJOGdZl4pquIrExICa/fzGy5qUcuG1LESj1InLHvAFres6MFm6v1mI0qopOJ5bqRiiCbbXKpQbqHDEDPA9Qia40Ucrc7QBXCK0R7GvGot04pTNhuFaKF3x06n3Ijf6tKehLiacyLh8vwdeaq16mocH2A0rrJQgrBBeDF2ssrRXLL6m7o+K6ZVLoBUeK0gkwXu83hnFEey5CauGx6zI09RMWw== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=westcontrol.com; Received: from SVAP279MB0239.NORP279.PROD.OUTLOOK.COM (2603:10a6:f10:6::13) by SV0P279MB0060.NORP279.PROD.OUTLOOK.COM (2603:10a6:f10:a::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5791.25; Fri, 11 Nov 2022 09:21:19 +0000 Received: from SVAP279MB0239.NORP279.PROD.OUTLOOK.COM ([fe80::7e3f:adb5:ce86:d0c]) by SVAP279MB0239.NORP279.PROD.OUTLOOK.COM ([fe80::7e3f:adb5:ce86:d0c%5]) with mapi id 15.20.5791.025; Fri, 11 Nov 2022 09:21:19 +0000 Message-ID: Date: Fri, 11 Nov 2022 10:21:18 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: -Wint-conversion, -Wincompatible-pointer-types, -Wpointer-sign: Are they hiding constraint C violations? Content-Language: en-GB To: Florian Weimer , Marek Polacek Cc: gcc@gcc.gnu.org References: <87mt8ysm3y.fsf@oldenburg.str.redhat.com> <87h6z6sjqp.fsf@oldenburg.str.redhat.com> From: David Brown In-Reply-To: <87h6z6sjqp.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: SV0P279CA0062.NORP279.PROD.OUTLOOK.COM (2603:10a6:f10:14::13) To SVAP279MB0239.NORP279.PROD.OUTLOOK.COM (2603:10a6:f10:6::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SVAP279MB0239:EE_|SV0P279MB0060:EE_ X-MS-Office365-Filtering-Correlation-Id: 77d93131-e281-458f-db29-08dac3c617d5 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: ckFaF3hM3fvII4IuFZwaI0P/M1Ek21KWnHy1LK3zNZgNngb1WZvgzqbGxfJoxYru7d2G4BaGMUzW1Y9q9Ls0oJECgZJpt7jYq13wzaO+WWH82t666oU+lCJKmYmZ4YWrx/roWbVjKOZ6MpWBv9HCA1CJZTfyTPbZvbPDl3uXesC8CdKHGNM0C4JeBBo+b8EM6GEkihP6WOMIpgVuBT9OGT/92a6xWM+sSCohPtApSi86shDgcsX9BqbKvB35vOkcieQH7Z4zs165P4zReKgD67kbSH4nDyp7d0aHxVA9Xo2UICWysHTi7PSAMU+dj/wA6j5lqQIrH3YrtuCFoEwd7yiMOL2j/A/A8S/khhZGYa598dH+XpiaANtAhWWns44kSBXW4BeFtAmAZ6SC4wvFPEToL3YMmN3KHb8ceicDDIVxnGgxOdArOW/nXe7hjOgNtf2tZXZStWbJ8cMzSyp+29PleC/fe7G6wORrQ5AGDRjVjtxr+4N/Dl5PT+hHxdJZxdGNG8cDZy+titU3QJlQGgbBbgMNjiecAbFoiTELBSv5lnC/IZhm/CzfPoLhr40MzSj4WdvKYWSl1YdeMhQGiOnk5S+loJ0v3jEnDnCkr2XiRe/3F0zVgegJuLLA24IsilEn1kr/fGMijB11KrSjekOx6Ivsn/CUUInv3p6f8RYg6xW8ewLRuzeE61qtF/7q4K0YAn7e8jPFPusDlQfP0mbxE2Dd+vcVkJADMadndl6AUnpY5kLa8lRqnIx47L6oNsDA6WnjoZnwdSRAvbih837NlWvWjLMp54A1NW5XwG0= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SVAP279MB0239.NORP279.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230022)(4636009)(376002)(396003)(39830400003)(366004)(136003)(346002)(451199015)(2616005)(36756003)(31686004)(86362001)(31696002)(83380400001)(2906002)(6506007)(38100700002)(53546011)(186003)(26005)(6512007)(4326008)(66556008)(8676002)(316002)(66946007)(66476007)(110136005)(41300700001)(8936002)(6486002)(478600001)(5660300002)(45980500001)(43740500002);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?TkRVWFJJU3J5SjFaUitGY3ZURXVuVFkyblFmZ3B2R2t0VU9acWZnbU9hbmVm?= =?utf-8?B?OE1BUTh1R2JrWnp3bTNyY1U3M0lXMzN2WlFvQVg5SzlmQ243UVlJMU5DQThN?= =?utf-8?B?eVE4MjIyOFMvN3ZYMVdnNDdVUUNRK0hFWG1FVGtHKzhWUEU2YlFRNVYzZVY1?= =?utf-8?B?M25PbktKaUJLOTIvMUkxbmFMTnM3OEt3eXQrTVNRNi94c1AvejYydXdlcURD?= =?utf-8?B?SDFJWVhKVFdYdTJMK2VKakFWMGd4Um12cDRqVGZaUW93L3hJVEVocmNic0lV?= =?utf-8?B?aWg3OUU3NGlRbU9ZMWZWUWFSaFcra2hhN2ZqNC91ZGVOcThJYUdBMUI3SWdJ?= =?utf-8?B?T0Yra0hNYjZVZUpSSUlUcDFKVm4ycmdrd1NYdDhGaWRYNUNTblVnZExZRSti?= =?utf-8?B?QnV5QzduYlVtTnZnaEdNMEtUSVNGaVY1RVNwNkpWeVBWTVg4d3NUektUT2wv?= =?utf-8?B?cDVCT3lwV2hmTXZrRE1HLzFPa0JHRFB2dXFpd3B5Nzg4TlM0L3RBM0RvcGJN?= =?utf-8?B?cXgvVE1KNUJxZmlveWIyZkVRd09HVCtkZWlUVHhYZThKcDA0amhBZERYcCtw?= =?utf-8?B?ZWpSNUN4REhGR2JCRU0wbklJbUh4UDdhWW5jektaZld2cWxHMTV2ZWF6a3E5?= =?utf-8?B?ZHhlOVp1bENwQWlWVWljd01XQVZDWGF4YUdXSkZnYjcxWkd5dmRvcDUwLzI2?= =?utf-8?B?SXhUaDF3MDRNMXRvL2c0dFQzYW5TZHBJbUIxRFBjMHNkS016cmk1eSt1eUJS?= =?utf-8?B?UDJHTEF0Q2VLdkxBWjVVV2VXdlZnbDZlYi9oS3hDOHhQVnpOamY4d2dMSUYy?= =?utf-8?B?cDg2SjZIeEsyY0pPM2hBWlJzcWlqVytwTVhsN2ZnNncrWFhXZjRYVVVXQUVO?= =?utf-8?B?TTAraFU1NGo5MjZCTHRGcHh3bHpCUFg0VFc5TDdXbXdYR09aSTZxZy9jTk5E?= =?utf-8?B?WTAxYmN3bE02YUUrZ1RQa0wyblpLelgxWlZHZTE4dzdwSXNoT3lEQTdLbkd4?= =?utf-8?B?L290Q3lWbVdRaXB4YXdDa2RPYzV6NThuVVJVaHR0UHFIenFGVEdpK2F2OGI4?= =?utf-8?B?eDh5VzI1dmcxSnV1RFBSbmJkTmNLSm0wUkVwUVNEdTIvL0wzN3NLL2ZNN05T?= =?utf-8?B?MHZ4ZHhQUmZDOG9jYXNCaXJEeTlLRW1zRFlMM280SkRmaUZud0hnaFFVQ0Ix?= =?utf-8?B?TU9zcVYwbVQ0a1JoYVBWOU82SzlPR3NPb0gvclFnVlBrZmxGL3ZNT3lkQVQ4?= =?utf-8?B?cHg1Z2Rsc0REMUkzQzhBWW1UMlF5cE5KZ29FektGTXU1bXRSZm9qVm1UeW05?= =?utf-8?B?SVZyMnFmZjRMSWZ6YUpMVTdCVTUyNnJwOW1ZRmRHU3lqamxYSHgzT3F2bkNS?= =?utf-8?B?ZVhtcENhNzNKMWpWZGVVYjhQVWpMc2E1RXJWR1EzWkhSa2I2TmlwN0dxK0cy?= =?utf-8?B?cll0bFJjMUJDSGFya29YcjF4Mm9hdm1XTDV5UThpVVVWMlR5M0Jpb0VPdU9L?= =?utf-8?B?emg0amdmV0JQY3JKVUl2d0pWZ3NPd0tURnFDVHNrWnMzOHRzaDVVUFppZHgr?= =?utf-8?B?YUpmN1hJSWdmY0tGK1c2Q1V0V2taQkRUU0dnTlBQZE1GZm51QTB2WmUydCt3?= =?utf-8?B?TmxuZjBFL0dBTE5CejBNZUJEc2pWL3M4b3I1WmtEZ3RYREl2eG9UWTNHTDVK?= =?utf-8?B?alFiVEc3cmcxazV0TXQrL0l6K0dDUHYxdHl3QndUdG5XcTlWZWVSZGJhNVVp?= =?utf-8?B?eWZWalM2T0NQZW00Y2U0REhPQmR0QmVlY2N3YU1MNjRpZVhOYWptRDFmMm9y?= =?utf-8?B?Sjl5TEpWUDd3V1hHeGkvRWNEbkRITnFPOWxQM3IydjNjVkRFMW1UVDRSY24w?= =?utf-8?B?VTgvN1RiQXNiQjdTdHlpREpRdld2OEU1blNXL0I2N0J1dExZL2hNUko0S28w?= =?utf-8?B?b3FRc1hFWkhjTCtDcUtOZVBvbm9tUFkyOHRFeU1ZQnJtalpiYkEvb3VmcWU0?= =?utf-8?B?V3AxeFlZQmxyUjV5dmFXN3BtK0VGaXFwdDRkY1pmRTdZSjNsd1BtTDlGcnJw?= =?utf-8?B?eEREQU1NYXFDRzdGQUZkckNjRnJuUFE5d0tGVVBTNGR4M3F3dWMrY08wNmsy?= =?utf-8?Q?MItEdBk253FgFJ6AdWAn+c22W?= X-OriginatorOrg: westcontrol.com X-MS-Exchange-CrossTenant-Network-Message-Id: 77d93131-e281-458f-db29-08dac3c617d5 X-MS-Exchange-CrossTenant-AuthSource: SVAP279MB0239.NORP279.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Nov 2022 09:21:19.8585 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: c75fbd3c-42ad-4db0-9cff-972faf83ae45 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: VHZqgLK1KEE55jEhJc7wU3QWULJsUQKelryMkpTuOjTzIgeunNIu550Dg0PIYOovyS2JrkOYYC6tFUwC0Q+5UA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SV0P279MB0060 X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 10/11/2022 20:16, Florian Weimer via Gcc wrote: > * Marek Polacek: > >> On Thu, Nov 10, 2022 at 07:25:21PM +0100, Florian Weimer via Gcc wrote: >>> GCC accepts various conversions between pointers and ints and different >>> types of pointers by default, issuing a warning. >>> >>> I've been reading the (hopefully) relevant partso f the C99 standard, >>> and it seems to me that C implementations are actually required to >>> diagnose errors in these cases because they are constraint violations: >>> the types are not compatible. >> >> It doesn't need to be a hard error, a warning is a diagnostic message, >> which is enough to diagnose a violation of any syntax rule or >> constraint. >> >> IIRC, the only case where the compiler _must_ emit a hard error is for >> #error. > > Hmm, you could be right. > > The standard says that constraint violations are not undefiend behavior, > but of course it does not define what happens in the presence of a > constraint violation. So the behavior is undefined by omission. This > seems to be a contradiction. > Section 5.1.1.3p1 of the C standard covers diagnostics. (I'm looking at the C11 version at the moment, but numbering is mostly consistent between C standards.) If there is at least one constraint violation or syntax error in the translation unit, then the compiler must emit at least one diagnostic message. That is all that is required. The C standard does not (as far as I know) distinguish between "error messages" and "warnings", or require that diagnostics stop compilation or the production of output files. So that means a conforming compiler can sum up all warnings and errors with a single "You did something wrong" message - and it can still produce an object file. It is even allowed to generate the same message when /nothing/ is wrong. The minimum behaviour to be conforming here is not particularly helpful! Also note that gcc, with default flags, is not a conforming compiler - it does not conform to any language standards. You need at least "-std=c99" (or whatever) and "-Wpedantic". Even then, I think gcc falls foul of the rule in 5.1.1.3p1 that says at least one diagnostic must be issued for a syntax or constraint violation "even if the behaviour is explicitly specified as undefined or implementation-defined". I am not entirely sure, but I think some of the extensions that are enabled even in non-gnu standards modes could contradict that. I personally think the key question for warnings on things like pointer compatibility depends on whether the compiler will do what the programmer expects. If you have a target where "int" and "long" are the same size, a programmer might use "pointer-to-int" to access a "long", and vice-versa. (This can easily be done accidentally on something like 32-bit ARM, where "int32_t" is "long" rather than "int".) If the compiler may use this incompatibility for type-based alias analysis and optimise on the assumption that the "pointer-to-int" never affects a "long", then such mixups should by default be at least a warning, if not a hard error. The primary goal for warnings and error messages must be to stop the programmer writing code that is wrong and does not do what they expect (as best the compiler can guess what the programmer expects). The secondary goal is to help the programmer write good quality code, and avoid potentially risky constructs - things that might work now, but could fail with other compiler versions, flags, targets, etc. It is not unreasonable to have warnings in this category need "-Wall" or explicit flags. (I'd like to see more warnings in gcc by default, and more of them as errors, but compatibility with existing build scripts is important.) > I assumed that there was a rule similar to the the rule for #error for > any kind of diagnostic, which would mean that GCC errors are diagnostic > messages in the sense of the standard, but GCC warnings are not. I believe that both "error" and "warning" messages are "diagnostics" in the terms of the standard. As I said above, the minimum requirements of the standard provide a very low bar here. A useful compiler must do far better (and gcc /does/ do far better). > > I wonder how C++ handles this. > > Thanks, > Florian > >