Re: Back branches vs. gcc 4.8.0

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: Back branches vs. gcc 4.8.0
Дата
Msg-id 1365213039.20916.9.camel@vanquo.pezone.net
обсуждение исходный текст
Ответ на Re: Back branches vs. gcc 4.8.0  (Peter Geoghegan <pg@heroku.com>)
Ответы Re: Back branches vs. gcc 4.8.0  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: Back branches vs. gcc 4.8.0
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: Page replacement algorithm in buffer cache