From: riche AT crl DOT com (Alex Stewart) Subject: Re: ASCII and BINARY files. Why? 2 Feb 1997 20:39:20 -0800 Sender: daemon AT cygnus DOT com Approved: cygnus DOT gnu-win32 AT cygnus DOT com Distribution: cygnus Message-ID: <199702030314.AA25561.cygnus.gnu-win32@crl8.crl.com> Original-To: jqb AT netcom DOT com (Jim Balter) Original-Cc: gnu-win32 AT cygnus DOT com In-Reply-To: <32F16B14.778C@netcom.com> from "Jim Balter" at Jan 30, 97 07:46:28 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 4189 Original-Sender: owner-gnu-win32 AT cygnus DOT com First off, let me say that when I posted my earlier message I wasn't in the best of moods (having been over and over and over this whole discussion in many different arenas already, and never seeing any end to it), and probably used some words I shouldn't have. My points, however, remain. > > POSIX is a flawed standard and always has been. It is fundamentally > > incompatible with the already-established ANSI standard for C programming while > > offering no substantial gains in its incompatibility. For this reason, the > > POSIX standard should and must be ignored where such incompatibilities arise as > > it is the only sane response to such an assenine flaw. > > Be careful of who you call asinine. POSIX *conforms* to ANSI C. ANSI C requires that files are opened in text mode by default. POSIX requires that there is no distinction between text and binary files. These two standards can coexist only on underlying systems where there is no distinction between file types (such as POSIX OSes). Win32 is not a POSIX OS environment in that it does distinguish between text and binary file types, and therefore ANSI C requires that files be opened with newline conversions by default, however the POSIX C standard requires that they not be. This is a fundamental incompatibility which renders POSIX inherently _incompatible_ with ANSI C (please note here that we are discussing the POSIX API standard, not the larger POSIX OS standards. Such issues in an OS specification would easily be dismissed by simply saying "well, Win32 isn't a POSIX OS", however the POSIX API specification should be applicable in an ANSI C, non-POSIX OS environment (as is exactly what people are attempting with GNU-Win32), and the fact that it cannot be is still a flaw) > Perhaps someone around here is an idiot and a moron, but it isn't > me or those in charge of the GNU project. Since GNU programs require > many POSIX extensions to ANSI C, such as, say, "stat", it is pointless > to try to make GNU programs *strictly* ANSI conforming. But programs > that conform to POSIX already conform (but not strictly) to ANSI C. They do not conform to ANSI C if they (for example) fopen a file without a "b" flag and expect to read/write binary data from it without problems. Many GNU utilities do this and are therefore incompatible with the ANSI C standard (strictly or otherwise). There is no reason for this as it is possible to design application code in such a way that it will function correctly under both systems, and therefore any code which does not is flawed and requires a bug fix. If the GNU project will not accept such bug fixes (thus requiring their software to be incompatible with ANSI standards) for no reason other than "we don't want it that way", then I reiterate my statement that they are morons. > I really don't think that understanding this distinction makes one > an idiot or a moron. I suggest you think twice or more before throwing > those words around. Understanding the distinction is not the issue. Requiring incompatibility for no reason is the issue, and it is still a valid one. If you don't like my choice of words, fair enough, but it doesn't change the actual issues involved. > While strictly conforming ANSI C programs can use fopen(file, "rt"), > they cannot use open, O_BIN, O_BINARY, or O_TEXT. And if they > do use "rt", they cannot depend upon its effects and still be strictly > conforming. Since the meaning of none of these is defined by either > ANSI C nor POSIX, their use is not portable. Under an ANSI-compatible system, "t" is unnecessary as all files are opened in text mode by default, therefore "depending on its effect" (its effect being that it doesn't need one) is a non-issue. One would only need to depend on its effect within an environment which itself did not conform to these standards anyway, and therefore the point becomes moot. -alex ------------------------------------------------------------------------------- Alex Stewart - riche AT crl DOT com - Richelieu @ Diversity University MOO http://www.crl.com/~riche "For the world is hollow, and I have touched the sky." - For help on using this list, send a message to "gnu-win32-request AT cygnus DOT com" with one line of text: "help".