Re: ToT glibc build problem with ToT GCC

[Carlos O'Donell <carlos at redhat dot com>]

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.

-- 
Cheers,
Carlos.