From: jqb AT netcom DOT com (Jim Balter) Subject: Re: ASCII and BINARY files. Why? 31 Jan 1997 00:49:15 -0800 Approved: cygnus DOT gnu-win32 AT cygnus DOT com Distribution: cygnus Message-ID: <32F16B14.778C.cygnus.gnu-win32@netcom.com> References: <199701310220 DOT AA04363 AT crl6 DOT crl DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.01Gold (WinNT; I) Original-To: gnu-win32 AT cygnus DOT com Original-Sender: owner-gnu-win32 AT cygnus DOT com Alex Stewart wrote: > > > Of course it's Unix-centric; it's GNU code, and GNU project is a Unix > > emulation. Of course it isn't entirely ANSI conformant; *no* complex or > > professional-quality code is entirely ANSI conformant (and I say this as a > > former member of X3J11, the ANSI C standards committee). GNU code isn't even > > entirely POSIX compliant, and POSIX is what's relevant here. > > 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. Any program that *strictly conforms* to ANSI C is acceptable to POSIX, and all conforming POSIX programs *conform* (but not strictly) to ANSI C. As the ANSI C standard states: A conforming implementation may have extensions (including additional library functions), provided they do not alter the behavior of an any strictly conforming program. (footnote) Strictly conforming programs are intended to be maximally portable among conforming implementations. Conforming programs may depend upon nonportable features of a conforming implementation. Of course, since POSIX specifies an *operating system*, it has many such extensions and features that aren't portable to other, non-POSIX, ANSI C systems. The idea that, say, access, alarm, chdir, chmod, chown, close, closedir, creat, dup, dup2, execl, fcntl, fdopen, fork, fstat, getcwd, getgid, open, read, write, to name just a few, offer "no substantial gains" seems, well, asinine. POSIX is carefully specified such that conforming POSIX implementations are conforming ANSI C implementations. I was on the ANSI C committee when we changes at the request of the POSIX committee to assure that this would be so. > > Why be sure of something that's probably false? The GNU project has limited > > goals, and they explicitly do not include 16-bit systems, systems that don't > > use / in filenames, systems that have separate text and binary modes, etc. > > Notably, in POSIX systems, reading as many bytes from a file as stat says it > > contains is perfectly appropriate behavior, and GNU code won't be "dumbed" > > down for the sake of non-POSIX systems. > > If you are stating that the GNU project will not accept submissions of code > fixes which bring GNU programs into ANSI-compliance, then either those in > charge of the GNU project are morons (for requiring their code to be > nonstandard) or you are an idiot (for speaking incorrectly on behalf of others > whose positions you do not know). I do not for certain know which is more > likely, but either option is unacceptable. > If you are not stating this, then I am not sure what you are attempting to say. 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. 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. > > Well, if djgpp defined O_BIN, then obviously djgpp would. There is no > > 't' or O_TEXT or O_BIN or O_BINARY mode in GNU. And there is no 't' > > mode defined in ANSI, nor is there any open() call in ANSI to even take > > an O_BINARY or O_TEXT flag. > > ..nor is it prohibited by the ANSI specification. 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. -- - For help on using this list, send a message to "gnu-win32-request AT cygnus DOT com" with one line of text: "help".