ToT glibc build problem with ToT GCC

[Martin Sebor]

On 8/30/19 6:25 AM, Carlos O'Donell wrote:
> On 8/29/19 2:36 PM, Martin Sebor wrote:
>> 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.
> 
> Is there only an interior zero-length array because you wrote replace[2]?
> 
> We don't need replace[2] if we have a union of enough bytes to hold a
> single struct charseq.

I think that should work.

Just as a heads up, there have been questions in WG14 about flexible
array members in recent years.  Some of them were raised by people
working on compilers who didn't have the same understanding of
the requirements, and as a result, whose compilers behaved
differently.  Since this is a bit of a murky area for some it's
possible that some of these union/flexarray/zero-length array
tricks might tickle their bugs.

Martin