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.

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

I would like to withdraw the above comment with regards to Watcom,
as although I got the name right (I can see that in my code), I
cannot remember the exact circumstances, and I failed to document
it at the time, and I am unable to reproduce it now, despite
trying every combination I could think of, so I have no evidence
of anything non-conforming about Watcom.

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.

MB> Common sense would dictate that a compiler vendor would provide this kind 
MB> of basic compatibility if easily available.  For example, ISO/ANSI would be 

I don't know.  There are two issues:

1. Whether Borland C++ is a 100% ISO conforming compiler.
2. How good Borland's support of posix is.

I am arguing number 1, you have not provided any evidence of anything
non-conforming about Borland.  Not one single skerek yet.

As for number 2, I don't know.  I know it's missing fork(), so it
can't be too good at posix.

MB> perfectly satisfied if an "__open()" function existed, and
the vendor could 
MB> provide a switch that maps "open()" to
"__open()" by a macro.  We are not 
MB> talking about low-level internals here.

You want an extension to ISO C, and you want it to be done in a
particular way, I have no comment.  I don't know and I don't care.

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.

MB> Supporting fork() is very hard under OS/2, and not particularly a good 

It's required for Posix.  Period.  EMX 0.9a supports it.  It can
do in the order of 10 forks per second on my 486-33, from memory.

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

Sure, I'm not arguing this, I don't care.

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. 

MB> This is ridiculous.  All Borland would have to do is name the functions 
MB> "__open()" and "__close()" instead, and then
offer a switch or define that 
MB> uses the preprocessor to create "open()" and
"close()" equivalents if 

What is ridiculous?  The fact that Borland is a 100% ISO conforming
compiler?

MB> wanted.  This is how Watcom handles most of the common extensions, using 
MB> the symbol "NO_EXT_KEYS" to disable extensions.

All of which has nothing to do with compiling 100% ISO conforming
code, or Borland's support thereof.

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.

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

A 100% ISO conforming compiler can do that if it wants to.  So
long as that compiler can compile 100% ISO conforming code, it
is conforming.  Whether applications should be using that macro
in that manner is a different story.

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. 

MB> So what?  ANSI/ISO requires "FOPEN_MAX" to be defined in
stdio.h.  If the 

Yes, you are correct.

MB> user is given a compiler switch or define that brings in extensions to the 
MB> standard names, then that is not especially different than the user writing 
MB> his own code, and it does not make the compiler non-conforming.

I didn't say that the compiler was non-conforming, I was saying
if you have extensions in stdio.h that are not documented in
ISO/IEC 9899:1990, then a compiler is not 100% ISO conforming
DURING THAT COMPILE.  Since posix requires extensions to be
brought in, you can't be strictly ISO and yet posix compliant at
the same time.

All your arguments have to do with posix stuff.  You have not provided
any evidence of anything that Borland is doing to make it non 
ISO-conforming.  BFN.  Paul.
@EOT:

---