[Pythonmac-SIG] MacOS X _POSIX_C_SOURCES and stuff

[Ronald Oussoren]

On 9-feb-2006, at 1:50, Bill Northcott wrote:

> 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 has nothing to do with C++ vs. C, but that Carbon/Carbon.h is  
not POSIX compliant (and that's likely also true for other Apple  
headers).

Ronald
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2157 bytes
Desc: not available
Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060209/7c4670e5/attachment.bin