Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!decwrl!infopiz!lupine!rfg
From: rfg@NCD.COM (Ron Guilmette)
Newsgroups: comp.std.c
Subject: Re: Frustrated trying to be portable
Message-ID: <4340@lupine.NCD.COM>
Date: 10 Mar 91 08:22:13 GMT
References: <4204@lupine.NCD.COM> <19085@rpp386.cactus.org> <31204@megaron.cs.arizona.edu>
Organization: Network Computing Devices, Inc., Mt. View, CA
Lines: 25

In article <31204@megaron.cs.arizona.edu> pab@cs.arizona.edu (Peter A. Bigot) writes:
>
>What we _really_ want then, is some convention to let us know what class of
>additional functions are provided in this particular implementation of a hosted
>compiler; e.g., __POSIX_STDC__ or some such.  _That_ I'd vote for; but it's a
>convention, not something that should be mandated by the language standard.

There are two important points I'd like to make here.

First, there are already conventions (or actually standards) estanblished
for the symbols that should get automatically defined in a true POSIX
environment.

Second, even if we consider the case that I was worried about (i.e. hosted
versus non-hosted) anything that might be done at this late date *must*
necessarily be only a "convention" (perhaps agreed upon my many many
implementors) because it is just too bloody late to change the ANSI C
standard.  (I for one would be satisfied with just a widespread convention
under which implementations would define __HOSTED_STDC__ if they qualified
as hosted implementations of ANSI C.)
-- 

// Ron Guilmette  -  C++ Entomologist
// Internet: rfg@ncd.com      uucp: ...uunet!lupine!rfg
// New motto:  If it ain't broke, try using a bigger hammer.