Re: fix for strict-alias warnings
От | Bruce Momjian |
---|---|
Тема | Re: fix for strict-alias warnings |
Дата | |
Msg-id | 200310111810.h9BIA3A25998@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: fix for strict-alias warnings ("Andrew Dunstan" <andrew@dunslane.net>) |
Список | pgsql-patches |
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
В списке pgsql-patches по дате отправления: