PE> There is no requirement for this, unless they interfere with the
PE> namespace of the resultant executable.

PT> If you take ANSI Standard seriously, it is required that non ansi library 
PT> functions be marked as such.

Can you quote a reference on this.  The only reference I know of is
that if a vendor-function pollutes the namespace when compiling in
"ISO-compliant" mode, then it must either start with a single _ and
a capital letter, or two _ and a lowercase letter, e.g. __cstart is
OK and _Cstart is ok.  In fact, Watcom C++ 10.0b calls theirs _cstart
from memory, which interferes with the namespace, thus making their
compiler non-conforming.

PT> MS C, when compiling with MS extensions, implicitly links in oldnames.lib 
PT> which just comtains function aliases to map the names to their underscore 
PT> form. When compiling strict ANSI, you have to write the functions in their 
PT> underscore form.

If they want to do that, that's OK, but it still doesn't make the
Borland approach wrong.

PT> CSET uses pragmas to map the names to their underscore form.

That's also their choice.

PT> Borland doesn't seem to do any, but at least 3.1 (the last BC I used) was 
PT> so stubborn to simply put the non ansi prototypes in ifdefs that make them 

Turbo C++ 1.0, the first ISO conforming compiler for DOS that I know
about, also had this.

PT> disappear when compiling ansi conforming (with an ifdef __STDC__) and the 
PT> Borland programmers topped that with a comment in the headers "who uses 
PT> these functions doesn't write standard C anyway, so let's keep the name 
PT> space clean".

Which they are entitled to do.

PT> You can't imagine how I was cursing when trying to port some GNU stuff, 
PT> because for most *NIX code, __STDC__ has to be defined to get prototypes 

Ah, but you see, you were trying to compiler UNIX code (ie somewhere
on the way to posix), you were not trying to compile ISO C code.  The
discussion was not about who has the best posix environment, but whether
there was something wrong with Borland's ISO-compliance claim.

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

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

PT> Compared to this behaviour, I vastly prefer the approach of MSC or CSET.

You prefer their posix environment to Borland's.  That's your choice.
I can't say which is better, because I've never written Posix-specific
code in my life.  Most of my code is ISO-compliant, and as I said,
although a stickler for that, I see very little wrong with Borland's
environment.  The only things that have been wrong were bugs.  And
Borland is indeed very buggy.  At least 1.0 and 1.5 were.  And I hate
their attitude to bugs (at least in Australia).

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

Secondly, let's assume you're really after a half-of-posix (including
open(), close(), read()) plus full ISO C environment.  Can Borland 
provide that to you?  First of all, the standard requires __STDC__
to be set equal to 1 for a conforming implementation.  But a 
conforming implementation, when a #include of stdio.h is done, will
not have polluted the namespace with a prototype for open().  I
can't remember whether or not posix requires open() to be prototyped
in stdio.h, my copy of the standard is at work.  Mind you, I need to
be there in a couple of hours anyway, so I may have a chance to look
that up.  Anyway, if POSIX does require this, then POSIX is
incompatible with ISO, so therefor anyone who is wanting to do a

#ifdef DO_PROTOTYPES

should not do

#ifdef __STDC__

if they then turn around and start writing non-ISO code (as most
people seem to do).  Therefore, it is a bug in the program, and
you should have simply converted all __STDC__ references to 
DO_PROTOTYPES, and then defined that in Borland.

Another *possibility* is that you can go "-D__STDC__=1" on the
command line compile of Borland to get what you want.

But first and foremost, I think the code you were porting was at
fault, asking for a conforming implementation when they know damn
well that they're not writing conforming code.  That is a massive
abuse of the __STDC__ macro.  In fact, I had the same problem
myself when compiling CVS on a Sun's acc compiler under SunOs 4.1.3.
The compiler only defined __STDC__ = 1 if you used a special compiler
option, but once you did that, a whole lot of other stuff stopped
working in the code.  My workaround was to change the #if __STDC__
to #ifdef __STDC__ but I now know that was the wrong solution (I was
only after a quick fix), and I'll inform our CVS guy about it and get
him to report it back to the people in the USA in charge of it.  I'm
not sure whether they accepted that change I made or not.

BFN.  Paul.

[12 hours or somesuch later]

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

---