PE> of days ago], BCOS2 1.5 doesn't have a fork(), which means they
PE> are not Posix-compliant already.  I very much doubt that Borland
PE> claim to be posix-compliant anyway.

PT> The only compiler (or better library) that has fork is the C library of the 
PT> emx gcc port. But the documentation strongly advises not to use fork as it 
PT> doesn't fit well into OS/2s process model.

Presumably you don't have an application that requires more than
1 fork per second anyway, and EMX will do better than that.

PE> #ifdef DO_PROTOTYPES

PE> should not do

PE> #ifdef __STDC__

PE> if they then turn around and start writing non-ISO code

PT> Of cause you're right. But tell that to the zillion people writing free 
PT> software mostly for the unix world :) But how do you distinguish a K&R 
PT> compiler from an ANSI compiler if not by testing for __STDC__ ? And 

How do you distinguish between a compiler that uses dos_findfirst()
and a compiler that uses findfirst()?

The answer is you can't, that's what a 

#ifdef DOS_STYLE_FINDFIRST

will do for you, if you need that.

Similary, a simple -DUSE_PROTOTYPES is all that is required to 
distinguish the two.

One thing I don't mind is if you go
#ifdef __STDC__
#ifndef USE_PROTOTYPES
#define USE_PROTOTYPES 1
#endif
#endif

And then use #if USE_PROTOTYPE throughout the code.

That way you can use the STDC macro in a non-harmful way.  The user can
always add -DUSE_PROTOTYPES to the compile line, regardless of the
way the compiler treats the __STDC__ macro.  However don't quote me
on that, I'm not familiar enough with K&R to know the fine detail
here.  Personally I think it is wrong to be using __STDC__ in the
manner above, if you are not writing ISO C code in the first place.

BFN.  Paul.
@EOT:

---