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
_______________________________________________
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
