Skip site navigation (1) Skip section navigation (2)

Re: seg regression failures

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: seg regression failures
Date: 2007-03-23 18:46:27
Message-ID: 12987.1174675587@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-patches
Magnus Hagander <magnus(at)hagander(dot)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

In response to

Responses

pgsql-patches by date

Next:From: Magnus HaganderDate: 2007-03-23 18:56:37
Subject: Re: seg regression failures
Previous:From: Magnus HaganderDate: 2007-03-23 18:22:50
Subject: Re: seg regression failures

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group