From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from albireo.enyo.de (albireo.enyo.de [37.24.231.21]) by sourceware.org (Postfix) with ESMTPS id A0DEA3858C54 for ; Fri, 12 May 2023 18:00:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A0DEA3858C54 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=deneb.enyo.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=deneb.enyo.de Received: from [172.17.203.2] (port=54519 helo=deneb.enyo.de) by albireo.enyo.de ([172.17.140.2]) with esmtps (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) id 1pxX3y-001qOU-0P; Fri, 12 May 2023 18:00:18 +0000 Received: from fw by deneb.enyo.de with local (Exim 4.96) (envelope-from ) id 1pxX3x-000Fkq-2w; Fri, 12 May 2023 20:00:17 +0200 From: Florian Weimer To: Gabriel Ravier Cc: Joseph Myers , Eli Zaretskii , Jakub Jelinek , jwakely.gcc@gmail.com, fweimer@redhat.com, gcc@gcc.gnu.org, arsen@aarsen.me Subject: Re: More C type errors by default for GCC 14 References: <87y1lx1avj.fsf@oldenburg.str.redhat.com> <83ednoapb6.fsf@gnu.org> <831qjoa0g0.fsf@gnu.org> <83o7ms8is7.fsf@gnu.org> <2ffbf210-1b58-737b-888c-4f84c5cc5e0f@gmail.com> <837ctg8e98.fsf@gnu.org> <83wn1g6w67.fsf@gnu.org> <83mt2c6tch.fsf@gnu.org> <871qjlh9t3.fsf@mid.deneb.enyo.de> <87jzxdfne0.fsf@mid.deneb.enyo.de> <3d157d9c-0504-b8b4-46f6-54ea90374765@gmail.com> Date: Fri, 12 May 2023 20:00:17 +0200 In-Reply-To: <3d157d9c-0504-b8b4-46f6-54ea90374765@gmail.com> (Gabriel Ravier's message of "Fri, 12 May 2023 19:55:51 +0200") Message-ID: <87cz35fn0u.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-5.5 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_NUMSUBJECT,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: * Gabriel Ravier: > On 5/12/23 19:52, Florian Weimer wrote: >> * Florian Weimer: >> >>> In summary, all these seems to be good candidates for errors by default: >>> >>> * int-conversion as errors (already raised separately >>> * -Wint-conversion for ?: >>> * parameter names in non-prototype function declarations >>> * the union wait function pointer compatibility kludge >>> * return-with-out-value for non-void functions >>> * -Wincomatible-pointer-types warning for ?: (but no error yet, see bel= ow) >> I think we have another problem. >> >> We do not warn by default for: >> >> int x; >> unsigned *p; >> >> p =3D &x; >> >> Isn't that a conformance issue because the pointers are incompatible, >> requiring a diagnostic? >> >> Furthermore, Unlike the char case, this tends to introduce >> strict-aliasing violations, so there is a good reason to treat this >> variant as an error (even if we would only warn for char * and >> unsigned char *). > > Isn't this allowed by the standard ? 6.5.7. Expressions states: > > An object shall have its stored value accessed only by an lvalue=20 > expression that has one of thefollowing types:[...] - a type that is the= =20 > signed or unsigned type corresponding to the effective type of the object Ahh, so no strict aliasing violation at least. Still I think we are required to diagnose the constraint violation in the pointer assignment. (Cerberus quotes C11 =A76.5.16.1#1, bullet 3 and 4 as violation.)