[OT] Re: How does C work on non-unix?
From: Arthur J. O'Dwyer (ajo_at_nospam.andrew.cmu.edu)
Date: Wed, 24 Dec 2003 15:47:23 -0500 (EST)
On Wed, 24 Dec 2003, Malcolm wrote:
> "J. J. Farrell" <firstname.lastname@example.org> wrote in message
> > It sounds like you have some misconception about the relationship
> > between C and the OS. If you explain why you think there might be a
> > problem using C on OSes that aren't written in C, someone should be
> > able to help clear it up for you.
> Things don't work as nicely on non-Unix boxes.
I guess you must use Unix a lot -- I've been a MS-DOS/Windows
person for most of my life, and I can't say I've noticed anything
about C or its myriad implementations that could reasonably be
described as "not nice." :)
> For instance, C has a
> printf() function, which means that arguments have to be passed from
> left to right on the stack.
Assuming one exists. ;) Either that, or the implementation has to
make some sort of [ad hoc] protocol to deal with variadic functions:
for example, it could pass doubles on the FPU stack, structs in a
buffer area in RAM,... you get the idea. Anyway, IMLE the vast
majority of compilers targeted at OSes targeted at desktop users use
the stack for passing arguments, so there's nothing special about
*nix in that regard.
> If the OS is written in a language using a different
> convention, either you have to have layers of wrapping, or you need a
> keyword like "pascal" to make it all work together.
Nonsense. The OS has nothing to do with the C library, in most
cases. Sure, Unix has some clever bits that let different programs
share the same object libraries [IANA Unix expert], but that's
not relevant to C programming any more than is the fact that Unix
also allows multiple users at a time.
DOS compilers like Borland, and many other compilers [DJGPP for
example], simply include their own "libc" implementations in the
compiler package itself. You write a program that wants to use
'printf'; the code for 'printf' gets linked into your executable.
No funky "pascal" keywords involved.
In fact, the only compiler family I know of that uses "pascal"
is Borland, and the purpose of their "pascal" keyword is to allow
linking of code between different languages -- to link C code
with Pascal code, e.g. That's completely different and OT here,
where we discuss only pure C code, not C-plus-Pascal-plus-Fortran
> Similarly, Unix treats a printer like a file, so output can be piped
> directly to it. Other OSes work in different ways, and stdin and stdout
> can't always be piped simply.
The C language doesn't understand the concept of "pipe" anyway;
that's a shell-level concept (which in Unix is built into the
kernel, and AFAIK in DOS is simulated directly at the level of
the shell), not a language-level concept.
> Sometimes it isn't even obvious how to provide a stdout / stderr. For
> instance, graphics and stderr don't mix on some systems.
^^^^^^^^ Neither here [ISO C] nor there [Unix]. :)
True, but then we get into hosted versus freestanding implementations,
and we'll be here all night with the embedded-systems folks telling
us again about how 'stdout' on ToastMaster 2000 is connected to the
brownness setting, blah blah blah. ;-)
Freestanding implementations aren't required to provide a lot of
the C library's functionality; the Standard covers all that, but I
don't know it off the top of my head.
Most hosted implementations *do* provide sensible semantics for
things like 'stdin', 'stdout', 'arg[cv]', 'fopen', and so on.