[Pythonmac-SIG] MacOS X _POSIX_C_SOURCES and stuff

[Bill Northcott]

On 09/02/2006, at 5:45 AM, Ronald Oussoren wrote:
>> #define	_POSIX_C_SOURCE 200112L
>> #include <Carbon/carbon.h>
>> int main ()
>> {
>> }
>
> Is that a valid POSIX program? Don't define _POSIX_C_SOURCE if you use
> system libraries that are not part of POSIX.

It is valid if somewhat minimal program in both C and C++.  As far as  
I understand the Posix etc. standards, they define system library  
functions which must be provided, along with their functional  
definitions and the headers which must be used to access them.  A C  
program is valid POSIX code if it uses the POSIX definitions of the  
system functions and includes.  You can use any other libraries you  
like as long as they do not use any of the POSIX function names.  So,  
yes I think that is valid POSIX C code.

The real problem here is that C++ is not part of the POSIX standard.   
So no C++ program can be POSIX compliant.  That is why the 'correct'  
tm fix is to conditionalise the POSIX defines with #ifndef  
__cplusplus or an equivalent.  I have now established that if that is  
done all of WXPython will build perfectly happily.

This is not the first time I have run into this sort of issue with  
some C/Fortran package that permits C++ extensions.  People easily  
forget that C++ (unlike Objective-C) is not a superset of C.  It is a  
different language.  The coders on the main package all too easily  
hack up C headers without bothering to think that they may get  
included in a C++ program and not function as they do in C.  As my  
test program, demonstrates Apple's Carbon is quite happy on a POSIX  
compliant system in a C program but NOT in C++ program.  This is not  
a failure to comply with the POSIX standards, because C++ is not  
POSIX compliant.

Cheers
Bill