Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!caen!news.cs.indiana.edu!arizona.edu!arizona!pab
From: pab@cs.arizona.edu (Peter A. Bigot)
Newsgroups: comp.std.c
Subject: Re: Frustrated trying to be portable
Message-ID: <31204@megaron.cs.arizona.edu>
Date: 4 Mar 91 00:34:05 GMT
References: <2956@cirrusl.UUCP> <4108@lupine.NCD.COM> <15333@smoke.brl.mil> <4204@lupine.NCD.COM> <19085@rpp386.cactus.org>
Organization: U of Arizona CS Dept, Tucson
Lines: 50

In article <19085@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes:
> In article <4204@lupine.NCD.COM> rfg@NCD.COM (Ron Guilmette) writes:
> >In article <15333@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes:
> >+It isn't necessary.  If the application requires library functions
> >+that are required for a hosted implementation but not for a
> >+freestanding implementation, then it couldn't survive being told
> >+that it is being compiled by a freestanding implementation anyway.
> >
> >I think that you have just assumed away a very real problem.
> >
> >Look.  I have a program which can work, and which can do useful things
> >even within an environment which only conforms to "standalone" subset
> >of ANSI C.
> 
> I have to side with Ron on this one.  Doug is making the assumption
> that the functions =must= exist for the program to be executed.  Yet
> there were quite a few commands, such as 'ls', which have traditionally
> been compiled "standalone" and "hosted" that managed to function quite
> well long before the arrival of ANSI C.  Anyone with access to the old
> source to "ls" can go see for themselves what I am talking about.

Although I don't have access to source to ls, I very much doubt that it's
conformant wrt an ANSI free-standing compiler, given that such a beast is not
obligated to provide _any_ library functions, let alone the "standard" ones.
Virtually no useful program is portable except in a hosted environment--how are
you going to do i/o?  Standalone is good for embedded controllers; that's about
it.

A hosted environment is required only to provide those library functions (all
of them) in section 4 of the "bible".  So I've got this neat program that needs
to call another, and I want it portable.  For a regular hosted environment, I
can call the system() function, wait for the return, and get my results that
way (although what they are is implementation defined).  But if I'm running
under Unix, I can fork and exec, and keep on working, picking up the results
later on.  Both are (with luck) hosted environments, and under the suggested
scheme, both would define __HOSTED_STDC__ (or whatever), but I wouldn't be able
to tell from that which block of code should be compiled.

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.

Peter
-- 
                     Peter A. Bigot -- pab@cs.arizona.edu
          Dept. of Computer Science, University of Arizona, Tucson AZ
---------------------------- The current quote is: ----------------------------
"What is this, again?" "Art." "Oh, yeah."  Lady Sarah Ferguson, the Duchess of
York (on being shown a steel shipping container supported by Barbie dolls).