[Pythonmac-SIG] MacOS X _POSIX_C_SOURCES and stuff
Ronald Oussoren
ronaldoussoren at mac.com
Thu Feb 9 07:44:58 CET 2006
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
More information about the Pythonmac-SIG
mailing list