More C type errors by default for GCC 14

[Alexander Monakov]

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