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                        |
  [EMAIL PROTECTED]               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?


Reply via email to