Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-lcc!rutgers!clyde!cbatt!osu-eddie!lum From: lum@osu-eddie.UUCP (Lum Johnson) Newsgroups: comp.lang.c Subject: Re: Supplementary standards (Re: ANSI C -- non-required features.) Message-ID: <2774@osu-eddie.UUCP> Date: Tue, 23-Dec-86 17:26:03 EST Article-I.D.: osu-eddi.2774 Posted: Tue Dec 23 17:26:03 1986 Date-Received: Wed, 24-Dec-86 18:46:30 EST References: <112@decvax.UUCP> <5458@brl-smoke.ARPA> <3987@watmath.UUCP> <2758@osu-eddie.UUCP> Reply-To: lum@osu-eddie.UUCP (Lum Johnson) Organization: The Ohio State University, IRCC/CIS DEC-2060 Lines: 30 Summary: Quick clarification to head off personal animosity In article <2758@osu-eddie.UUCP> lum@osu-eddie.UUCP (Lum Johnson) writes: >> The committee has refused to define "\e" as the string escape sequence for >> the ASCII character ESC on the grounds that [for implementations that] won't >> be using ASCII .. this would be impossible .. to implement. But [that]'s no >> reason for not [saying] "for implementations using the ASCII character set, >> '\e' will be the ESC character" [or defining] appropriate escapes for other >> common character sets such as Latin 1. >> > I believe that may be intentional. Have you ever heard of the principle of > "Equal Disadvantage"? If we put "\e" into the standard just because it is > obviously correct for ASCII implementations, it would be a significant > disadvantage to vendors of alien equipment which use non-standard char sets. > ASCII implementations would become even more interportable than they now are. > To reduce the already fearsome disadvantage to alien vendors, it is necessary > to mandate an uneven playing field which treats them as more equal than they > truly are. In other words, omissions in the standard may be (and I believe > should be viewed as) a covert non-economic subsidy to such alien vendors. > They will not lead to "needless" differences at all; differences, yes, but > needless, no, not from the viewpoint of protecting said alien vendors. Before anyone mistakes this for a personal attack, I wish to say that this was definitely _not_ so intended. I am impugning the process, not the people. I'm just PO'd that the process is failing even to mention other well-known standards, let alone to state definitively how this standard should interact with them, when there is no objective reason for permitting such an omission. Lum Johnson lum@ohio-state.arpa ..!cbosgd!osu-eddie!lum Enufk is enufk - that's all I can stands, I can't stands no more. - Popeye (Corrected quote - It's funnier with "stands" instead of "takes", anyhow.)