Andrew Dunstan wrote:
> Tough words! :-)
>
> ISTM the best thing would be to back out the patch, add -fno-strict-aliasing
> for gcc, and add a TODO to fix this thoroughly.
>
> Having -fstrict-aliasing on and ignoring the warnings doesn't seem like a
> sound strategy. I think we should fix it or turn it off. The web is littered
> with projects that got bizzare happenings when they turned it on without any
> accompanying code changes.
>
> I agree with Tom that my patch isn't ideal (I thought I said as much).
> Fixing it thoroughly will require some significant code changes, though. We
> seem to be far too close to 7.4 release to contemplate that.
I have backed out the patch.
Looking at the case in tablecmds.c and proc.c, the first was assigning a
struct with a NodeTag pointer as its first element to another struct
with NodeTag as its first element. In fact, we do this all over the
place, having different structure pointers with a start element of
NodeTag. The proc.c cases were using MemSet, which was checking if the
int* as aligned for int* access. In fact, we could change MemSet to
always take a void *, and do the int* casting when we access it after
testing for alignment.
The big question in my mind is whether there there is other struct *
passing that could be masked right now by void* casting, and if so, do
they have different first elements? This determined whether we do
-fstrict-aliasing for gcc, or fix just these few cases.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
