Path: utzoo!utgpu!watmath!rbutterworth From: rbutterworth@watmath.waterloo.edu (Ray Butterworth) Newsgroups: comp.std.c Subject: Inappropriate topics. Message-ID: <28442@watmath.waterloo.edu> Date: 17 Aug 89 19:59:17 GMT References: <148@trigon.UUCP> <207600029@s.cs.uiuc.edu> <941@lakesys.UUCP> <5692@ficc.uu.net> Organization: U of Waterloo, Ontario Lines: 50 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.