Re: ToT glibc build problem with ToT GCC

[Martin Sebor <msebor at gmail dot com>]

On 8/29/19 11:54 AM, Carlos O'Donell wrote:
> On 8/29/19 1:28 PM, Martin Sebor wrote:
> > A longer term solution is to replace the array with a suitably
> > aligned char buffer and write the data into it, e.g., like this:
> >
> >    union {
> >      struct charseq replace[2];
> >      char buf[sizeof (struct charseq) * 2];
> >    } u;
> >
> >    u.replace[0].nbytes = 1;
> >    const char s[] = "?";
> >    memcpy (u.buf + offsetof (struct charseq, bytes), "?", 2);
> >
> > This is still iffy but it won't trigger an out-of-bounds warning.
> > This code should still be flagged for the declaration of an object
> > with an internal zero-length array, so that will need to be dealt
> > with when such a warning is introduced (e.g., by suppressing
> > the warning).
>
> Why is this iffy? This is the kind of solution I was thinking of using.
>
> The alternative is an entirely new type that has a non-zero-length
> array that can be used for static object allocation like this, but then
> you need to cast between them in a safe way?

It's iffy because of the interior zero-length array.

GCC accepts zero-length array members anywhere but it doesn't
always avoid assuming their elements don't overlap other members.
Some other compilers don't allow zero-length arrays in definitions
where they're followed by another member or element of a larger
array.  I'd like to see GCC warn for such uses because of
the overlapping problem.

Martin

PS For example, GCC folds the test below to false.  Clang does
the same with slightly different test cases.

  struct charseq replace[2];

  void f (int i)
  {
    int x = *replace[1].name;

    replace[0].bytes[i] = 0;

    if (x != *replace[1].name)
      __builtin_abort ();
  }