Re: seg regression failures
От | Tom Lane |
---|---|
Тема | Re: seg regression failures |
Дата | |
Msg-id | 12987.1174675587@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: seg regression failures (Magnus Hagander <magnus@hagander.net>) |
Ответы |
Re: seg regression failures
|
Список | pgsql-patches |
Magnus Hagander <magnus@hagander.net> writes: > The SEG parameters going into seg_overlap() look perfectly correct, and > seg_overlap() actually returns 0. But this is somehow later turned into > 't'. Any pointers for where to look for how that happens? I'll betcha that MSVC is generating code that only sets the low-order byte of the return register (EAX likely) where GCC tends to set the whole register. So when the returned value is taken as a Datum, it might contain some garbage. Seems like we need to either reconsider the definition of DatumGetBool, or decree that old-style functions returning bool are broken. I'm a bit surprised this hasn't come up before, actually, since it seems like it could happen on a lot of architectures. Fixing DatumGetBool is probably the right thing to do. -#define DatumGetBool(X) ((bool) (((Datum) (X)) != 0)) +#define DatumGetBool(X) ((bool) (((bool) (X)) != 0)) regards, tom lane
В списке pgsql-patches по дате отправления: