Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!husc6!cmcl2!brl-adm!brl-smoke!gwyn From: gwyn@brl-smoke.UUCP Newsgroups: comp.lang.c Subject: Re: Distorting fseek semantics Message-ID: <6423@brl-smoke.ARPA> Date: Sat, 12-Sep-87 16:59:45 EDT Article-I.D.: brl-smok.6423 Posted: Sat Sep 12 16:59:45 1987 Date-Received: Sun, 13-Sep-87 08:49:31 EDT References: <493@its63b.ed.ac.uk> <6061@brl-smoke.ARPA> <8560@utzoo.UUCP> <1129@bsu-cs.UUCP> <27734@sun.uucp> <1134@bsu-cs.UUCP> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 56 In article <1134@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >I believe at one time ANSI actually allowed a binary file to return >more characters on a read than had been ever written to it. That such >bizarre behavior could be even considered, let alone included in the >draft, shows how much pressure there must be on ANSI. An implementation-defined number of NUL characters (bytes) is still allowed to be appended to a binary stream that was earlier written under the same implementation (not necessarily the same process). It doesn't matter how "bizarre" you find this, it's a fact that some operating systems are like that. It's much better that a programmer be warned that this can happen than to have him remain ignorant of such important facts of life. Nobody in his right mind would attempt to guarantee that all code already written for UNIX systems will work unchanged on all other operating systems. Binary search on text files is a good example of exploiting non-portable system characteristics. It is simply not true that existing code for that would be portable "if only" ANSI C would insist that text files be treatable as randomly- addressable byte arrays, except in the trivial sense that there would then be fewer conforming implementations to port the code to. Vendors who can will undoubtedly give the interface to text files as many UNIX-like properties as possible, since that will cause their customers the least trouble. Vendors who can't, won't anyway; better that they have standard specifications for the things that they CAN do. I don't know what you mean by "pressure on ANSI". The X3J11 committee is trying to produce the most useful feasible C standard. Does that constitute some sort of "pressure"? I really wish contributors to this news group would limit their discussion of the proposed ANSI standard for C to asking questions and making technical suggestions. These attacks on the competence of X3J11 do nothing but show how little the attackers understand about the issues involved. It is perhaps worth noting that not long ago Dennis Ritchie commended the work done by X3J11; I haven't heard that he's since changed his mind. Now, there might be someone out there with a better understanding of C, UNIX, and principles for elegance in software design than Dennis, but I rather doubt it. P.S. Although I'm an X3J11 member, I'm not an official spokesman for them. I would like to remark that I'm proud to be associated with such a group of bright, dedicated people with a broad spectrum of backgrounds, most or all of whom are more knowledgeable than I am in various issues directly related to the C standardization effort. I doubt that any other approach to C standardization would produce overall results better than this one. X3J11 can of course use constructive input from others; you had one opportunity to provide that earlier and will have another chance to review and comment on the revised proposed standard soon (perhaps before the end of this calendar year). Please note, however, that the variety of environments and applications make conflicting demands, so that often a compromise solution is required for "optimality" (in the linear-programming sense).