Re: Back branches vs. gcc 4.8.0 - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Back branches vs. gcc 4.8.0
Date
Msg-id 1365213039.20916.9.camel@vanquo.pezone.net
Whole thread Raw
In response to Re: Back branches vs. gcc 4.8.0  (Peter Geoghegan <pg@heroku.com>)
Responses Re: Back branches vs. gcc 4.8.0
List pgsql-hackers
On Fri, 2013-04-05 at 23:44 +0100, Peter Geoghegan wrote:
> On Fri, Apr 5, 2013 at 11:39 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> > The respective macro magic is already in place, its just not used in all
> > places. The problem is more that we can't easily use it in all places
> > because e.g. in the one case mentioned here the array isn't in the last
> > place *in the back branches*.
> 
> Are you proposing that we use the FLEXIBLE_ARRAY_MEMBER macro in every
> single place where we currently use the one element array pattern? I
> count one place where we currently use FLEXIBLE_ARRAY_MEMBER. It'd be
> pretty ugly to have that everywhere, in my opinion.

Background: The reason I put in that one use of FLEXIBLE_ARRAY_MEMBER is
that at one point clang threw a warning about the old coding.  There
were no warnings about the other sites that use array[1].

The reason that the whole code wasn't converted right away was (besides
a lot of legwork with sizeof and offsetoff) that flexible array members
aren't allowed in the middle of structs.  Which eventually led to the
mentioned commit 8137f2c32322c624e0431fac1621e8e9315202f9.

If someone wants to go through and change the rest of the code to use
FLEXIBLE_ARRAY_MEMBER, I won't mind.  But I think it actually has
nothing to do with the current bug or future-proofing anything.  All
compilers tolerate the current coding.





pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Back branches vs. gcc 4.8.0
Next
From: Amit Kapila
Date:
Subject: Re: Page replacement algorithm in buffer cache