Magnus Hagander <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
