Paul Edwards wrote in a message to Philipp Thomas:

 PE> when compiling in "ISO-compliant" mode, then it must either
 PE> start with a single _ and a capital letter, or two _ and a
 PE> lowercase letter, e.g. __cstart is OK and _Cstart is ok.  In
 PE> fact, Watcom C++ 10.0b calls theirs _cstart from memory,
 PE> which interferes with the namespace, thus making their
 PE> compiler non-conforming.

Watcom is very careful about this, and uses macros to map the single
underscore versions of labels to the double underscore versions.  If the
compiler is being operated with the necessary switches for strictly
compliant mode, then these macros are not applied.

PT> and/or headers like stdlib.h included. I went through all BC headers and 
PT> eliminated all these stupid ifdefs.

 PE> You tried to turn an ISO-conforming compiler into a
 PE> Posix-conforming compiler.  That's your choice.

Common sense would dictate that a compiler vendor would provide this kind
of basic compatibility if easily available.  For example, ISO/ANSI would be
perfectly satisfied if an "__open()" function existed, and the
vendor could provide a switch that maps "open()" to
"__open()" by a macro.  We are not talking about low-level
internals here.

 PE> Now to the SEPARATE question of how posix-compliant Borland
 PE> are. For starters, [I just got hold of the Posix .1 standard
 PE> a couple of days ago], BCOS2 1.5 doesn't have a fork(),
 PE> which means they are not Posix-compliant already.  I very
 PE> much doubt that Borland claim to be posix-compliant anyway.

Supporting fork() is very hard under OS/2, and not particularly a good
idea.  If you take multi-processing Unix code and blindly port it to OS/2,
you will not take advantage of any of the improvements OS/2 offers over
Unix, especially multi-threading.  The real trouble with fork() is getting
back the completion code, since this is handled in a convoluted manner
under Unix that is difficult to replicate exactly under OS/2.

 PE> Secondly, let's assume you're really after a half-of-posix
 PE> (including open(), close(), read()) plus full ISO C
 PE> environment.  Can Borland  provide that to you?  First of
 PE> all, the standard requires __STDC__ to be set equal to 1 for
 PE> a conforming implementation.  But a  conforming
 PE> implementation, when a #include of stdio.h is done, will not
 PE> have polluted the namespace with a prototype for open().  I
 PE> can't remember whether or not posix requires open() to be
 PE> prototyped in stdio.h, my copy of the standard is at work. 

This is ridiculous.  All Borland would have to do is name the functions
"__open()" and "__close()" instead, and then offer a
switch or define that uses the preprocessor to create "open()"
and "close()" equivalents if wanted.  This is how Watcom handles
most of the common extensions, using the symbol "NO_EXT_KEYS" to
disable extensions.

 PE> But first and foremost, I think the code you were porting
 PE> was at fault, asking for a conforming implementation when
 PE> they know damn well that they're not writing conforming
 PE> code.  That is a massive abuse of the __STDC__ macro.  In
 PE> fact, I had the same problem myself when compiling CVS on a
 PE> Sun's acc compiler under SunOs 4.1.3.

Nearly all Unix compilers use the __STDC__ mode to determine whether
K&R or prototype style will be used.

 PE> Although posix doesn't require open() to be in stdio.h, it
 PE> does require STREAM_MAX to be defined in stdio.h. 
 PE> Therefore, you can't be both STDC and posix at the same
 PE> time, so it's really the fault of the programmer for abusing
 PE> STDC, not Borland for their particular implementation. 

So what?  ANSI/ISO requires "FOPEN_MAX" to be defined in stdio.h.
 If the user is given a compiler switch or define that brings in extensions
to the standard names, then that is not especially different than the user
writing his own code, and it does not make the compiler non-conforming.
 
-- Mike


---