Re: python cleanup

Andrew Dunstan <andrew@dunslane.net>

From: Andrew Dunstan <andrew@dunslane.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Peter Eisentraut <peter_e@gmx.net>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2011-07-31T23:28:16Z
Lists: pgsql-hackers

Attachments


On 07/25/2011 12:03 PM, Tom Lane wrote:
> Andrew Dunstan<andrew@dunslane.net>  writes:
>> On 07/25/2011 10:52 AM, Tom Lane wrote:
>>> What is features.h, and have its authors read the POSIX standard?
>>> AFAICS they have no business defining this symbol.
>>      [andrew@emma ~]$ rpm -q -f /usr/include/features.h
>>      glibc-headers-2.13-1.x86_64
> Oh, for some reason I was thinking this was mingw-specific.
>
> [ pokes around ... ]  I still think it's a bad idea for the header
> files to be defining this, but they'll probably point at the part
> of the POSIX spec that says the results are undefined if the macro
> is changed after the first system header is #included.
>
> I can't immediately think of any way to actually do what you were
> trying to do (ie, save and restore the definition of the macro).
> I wonder whether it would be good enough to do this:
>
> 	#include postgres.h
>
> 	#include everything else we want except python headers
>
> 	#undef _POSIX_C_SOURCE
> 	#undef _XOPEN_SOURCE
>
> 	#include python headers
>
> 	... rest of .c file ...
>
> This should only fail if (a) some macro imported from system headers
> attempts to test the value of a feature macro, and (b) the results
> vary between the system default setting and the setting the python
> headers selected.  Neither of these things seem very probable.


OK, attached gives a clean build and passes regression on my Windows box 
that builds with Python. I had to undefine a few more things and save 
and restore our *snprintf settings (with code borrowed from plperl.h, 
where we did this sort of cleanup a while ago).

cheers

andrew