Noah Misch <noah@leadboat.com> writes:
> On Fri, Apr 22, 2016 at 03:54:48PM +0000, Tom Lane wrote:
>> Convert contrib/seg's bool-returning SQL functions to V1 call convention.
>>
>> It appears that we can no longer get away with using V0 call convention
>> for bool-returning functions in newer versions of MSVC. The compiler
>> seems to generate code that doesn't clear the higher-order bits of the
>> result register, causing the bool result Datum to often read as "true"
>> when "false" was intended. This is not very surprising, since the
>> function thinks it's returning a bool-width result but fmgr_oldstyle
>> assumes that V0 functions return "char *"; what's surprising is that
>> that hack worked for so long on so many platforms.
> Does this warrant a change to the "Section 2" comment of postgres.h,
> explaining that its precautions no longer suffice everywhere?
Hmmm ... looking at that again, and particularly at the definition
of DatumGetBool, I wonder whether the true problem is that a cast to
bool is being interpreted differently than we expect. The intention,
as per its comment, is that we should consider only the rightmost byte
of the Datum value but consider any nonzero value of that byte as "true".
But if MSVC is now treating bool according to C99 rules, it might be
interpreting "(bool) (X)" as "(X) != 0".
It would be interesting to find out if VS2015 passes with this commit
reverted and instead defining DatumGetBool as, say,
#define DatumGetBool(X) ((bool) (GET_1_BYTE(X) != 0))
regards, tom lane