From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Peter Geoghegan <pg(at)heroku(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Back branches vs. gcc 4.8.0 |
Date: | 2013-04-06 16:59:14 |
Message-ID: | 6111.1365267554@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> 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.
The reason I'm thinking it's a good idea is that it would expose any
remaining places where we have nominally var-length arrays embedded in
larger structs. Now that I've seen the failures with gcc 4.8.0, I'm
quite worried that there might be some more declarations like that
which we've not identified yet, but that by chance aren't causing
obvious failures today. (This is also why I'm not that excited about
trying to fix things "properly" in the back branches compared to
selecting -fno-aggressive-loop-optimizations: I'm afraid there might
be more to it than just the one commit.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jaime Casanova | 2013-04-06 18:16:51 | isolation test fails on installcheck |
Previous Message | Andres Freund | 2013-04-06 14:44:03 | Re: corrupt pages detected by enabling checksums |