On 19/02/15 15:00, Tom Lane wrote:
> Michael Paquier <michael.paquier@gmail.com> writes:
>> On Thu, Feb 19, 2015 at 7:29 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Moreover, if we have any code that is assuming such cases are okay, it
>>> probably needs a second look. Isn't this situation effectively assuming
>>> that a variable-length array is fixed-length?
>> AFAIK, switching a bunch of things to use FLEXIBLE_ARRAY_MEMBER has
>> put a couple of things in light that could be revisited:
>> 1) tuptoaster.c, with this declaration of varlena:
>> struct
>> {
>> struct varlena hdr;
>> char data[TOAST_MAX_CHUNK_SIZE]; /* make
>> struct big enough */
>> int32 align_it; /* ensure struct is
>> aligned well enough */
>> } chunk_data;
> I'm pretty sure that thing ought to be a union, not a struct.
>
>> 2) inv_api.c with this thing:
>> struct
>> {
>> bytea hdr;
>> char data[LOBLKSIZE]; /* make struct
>> big enough */
>> int32 align_it; /* ensure struct is
>> aligned well enough */
>> } workbuf;
> And probably this too.
>
>> 3) heapam.c in three places with HeapTupleHeaderData:
>> struct
>> {
>> HeapTupleHeaderData hdr;
>> char data[MaxHeapTupleSize];
>> } tbuf;
> And this, though I'm not sure if we'd have to change the size of the
> padding data[] member.
>
>> 5) reorderbuffer.h with its use of HeapTupleHeaderData:
> Hmm. Andres will have to answer for that one ;-)
>
> regards, tom lane
>
>
Curious, has this problem been raised with the gcc maintainers?
Is this still a problem with gcc 5.0 (which is due to be released soon)?
Cheers,
Gavin
