Frustrated trying to be portable

[Ron Guilmette]

In article <2956 at cirrusl.UUCP> dhesi%cirrusl at oliveb.ATC.olivetti.com (Rahul Dhesi) writes:
>In <1991Feb17.203337.20569 at uokmax.ecn.uoknor.edu>
>
>2. Use a symbol STDINCLUDE.  If it's defined, include the ANSI standard
>include files.  If not, include traditional C include files only.
>Define it wisely.
>
>     #ifdef STDINCLUDE
>     # include <stdlib.h>
>     # include <string.h>
>     #else
>       extern char *malloc();
>       extern char *strcpy(), *strncpy(), *strcat();
>       extern int strlen();
>     #endif
>
>(Do not use __STDC__ above -- it's quite possible for a C environment
>that isn't strictly ANSI C to still provide ANSI C include files.)

It occurs to me that the x3j11 committee messed up by allowing there to
be two *different* but equally *legal* variants of "ANSI C" (i.e.
standalone and hosted) without providing users with any mandated (and
reliable) way to differentiate between these two variants of "ANSI C".

It would have been nicer if the x3j11 committee had *required* there to
be an additional symbol defined (e.g. __HOSTED_STDC__) *only* for "hosted"
implementations.

Why wasn't this done?

Now that this mistake has been made, is there any "common practice" or
defacto standard method by which a program can check to see if it is being
compiled by/within a "hosted" implementation or a "standalone" implementation?

If not, I'd like to propose that ANSI C compilers should define the extra
symbol __HOSTED_STDC__ if they are part of a "hosted" implementation.  I'm
proposing only that ANSI C implementors should try to make this a common
practice.  It's too late now to go back and change the ANSI C standard.

-- 

// Ron Guilmette  -  C++ Entomologist
// Internet: rfg at ncd.com      uucp: ...uunet!lupine!rfg
// Motto:  If it sticks, force it.  If it breaks, it needed replacing anyway.