From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=LUiM=BB=ispras.ru=amonakov@sourceware.org>
Received: from mail.ispras.ru (mail.ispras.ru [83.149.199.84])
	by sourceware.org (Postfix) with ESMTPS id 640A23858C54
	for <gcc@gcc.gnu.org>; Fri, 12 May 2023 18:08:06 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 640A23858C54
Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=ispras.ru
Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=ispras.ru
Received: from [10.10.3.121] (unknown [10.10.3.121])
	by mail.ispras.ru (Postfix) with ESMTPS id 8106040737AC;
	Fri, 12 May 2023 18:08:03 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 mail.ispras.ru 8106040737AC
Date: Fri, 12 May 2023 21:08:03 +0300 (MSK)
From: Alexander Monakov <amonakov@ispras.ru>
To: Gabriel Ravier <gabravier@gmail.com>
cc: Florian Weimer <fw@deneb.enyo.de>, Joseph Myers <joseph@codesourcery.com>, 
    Eli Zaretskii <eliz@gnu.org>, Jakub Jelinek <jakub@redhat.com>, 
    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
In-Reply-To: <3d157d9c-0504-b8b4-46f6-54ea90374765@gmail.com>
Message-ID: <4989d9fb-366a-4103-aedc-ce725ef131a8@ispras.ru>
References: <87y1lx1avj.fsf@oldenburg.str.redhat.com> <83ednoapb6.fsf@gnu.org> <CAH6eHdS0KEyfLdE9fvTJ3aLtudKXcL9PyqPASJJVEgTMD6FaUQ@mail.gmail.com> <831qjoa0g0.fsf@gnu.org> <ZFuH9VCEzzN9JoWz@tucnak> <83o7ms8is7.fsf@gnu.org> <2ffbf210-1b58-737b-888c-4f84c5cc5e0f@gmail.com>
 <837ctg8e98.fsf@gnu.org> <ZFuoopSgnEjHomYt@tucnak> <83wn1g6w67.fsf@gnu.org> <ZFvALcZrJwDmCmqK@tucnak> <83mt2c6tch.fsf@gnu.org> <c1215de9-1ef9-fa52-f5d9-32f1f2df20@codesourcery.com> <871qjlh9t3.fsf@mid.deneb.enyo.de> <87jzxdfne0.fsf@mid.deneb.enyo.de>
 <3d157d9c-0504-b8b4-46f6-54ea90374765@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_NUMSUBJECT,KAM_SHORT,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: <gcc.gcc.gnu.org>


On Fri, 12 May 2023, Gabriel Ravier via Gcc wrote:

> On 5/12/23 19:52, Florian Weimer wrote:
> > I think we have another problem.
> >
> > We do not warn by default for:
> >
> >    int x;
> >    unsigned *p;
> >
> >    p = &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 
> expression that has one of thefollowing types:[...] - a type that is the
> signed or unsigned type corresponding to the effective type of the object

The standard allows aliasing, but not assigning pointers without a cast.

This is valid:

  unsigned x;

  int *p = (void *)&x;

  *p = 0;

This is not valid (constraint violation):

  unsigned x;

  int *p = &x;

In GCC this is diagnosed under -Wpointer-sign:

  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25892

Alexander