🚀 go-pugleaf

In article <5692@ficc.uu.net>, peter@ficc.uu.net (Peter da Silva) writes:
> Subject: Re: ReadKey like Function in C
> I redirected this back to comp.std.c, because I'm really not interested
> in the POSIX standard here. The main reason POSIX comes up in this group
> is because of holes in the ANSI C standard. Many of them are reasonably
> brushed aside as outside the scope of the standard, but then the POSIX
> standard is referred to as something that will cover them... and as this
> message (I hope) shows, that just ain't so...
> 
> I expressed dismay that POSIX mandated fork():
> ... 
> But this rules out POSIX support for a wide variety of operating systems.
                                                         ^^^^^^^^^^^^^^^^^
But POSIX in effect IS an operating system.

ANSI C defines a minimal compiler language that can reasonably
be implemented on a variety of operating systems.  If a feature
is very OS-dependent, it doesn't belong in that standard.
ANSI C can't mandate such functions as "get one character from
the terminal" or "turn on this file's setgid bit" without making
the compiler useless for a significant number of operating systems.

POSIX defines a minimal (well not really) operating system that 
can reasonably be implemented on a variety of different hardware
configurations.  If a feature is very hardware specific, it
doesn't belong in that standard.  POSIX can't mandate such
functions as ascbcd("ascii string", &bcdstring), which converts
the ascii characters to 6-bit BCD characters and inserts them
6 per 36-bit word into the bcdstring target, without making
the OS useless on a significant number of machine architectures.

I use such a machine, but I wouldn't expect 36-bit words
to be required in order to support a portable operating system,
much less be required to support a portable compiler.
If I am writing something that relies on 36-bit words,
I am writing something very machine-specific and if I expect
any support for it, it would be from a machine-specific library,
not from one mandated by ANSI C or by POSIX.

The point is, if you are trying to do something that is OS-specific,
you shouldn't be asking a portable compiler to provide the
functionality, and if you are trying to do something that is
hardware-specific, you shouldn't be asking a portable operating
system to provide the functionality.

setgid is very OS dependent; if you want to talk about that,
it belongs in UNIX or POSIX discussions, not in comp.std.c.
36-bit words are very hardware dependent; if you want to talk
about that, it belongs in comp.arch.thirtysix or comp.dps8, not
in comp.std.c or comp.std.unix.