Supplementary standards (Re: ANSI C -- non-required features.)

Lum Johnson lum at osu-eddie.UUCP
Sun Dec 21 06:33:33 AEST 1986


[It's unclear who made remarks prefaced by ">> ".  Sorry.]

In article <3987 at watmath.UUCP> rbutterworth at watmath.UUCP (Ray Butterworth) writes:
>In article <5458 at brl-smoke.ARPA>, gwyn at brl-smoke.ARPA (Doug Gwyn) writes:
>>> The standard should specify .. escape sequences for implementations that
>>> use the USASCII or Latin 1 alphabets, ...
>>
>> So long as we don't mandate ASCII/ISO character sets, this is infeasible.
>
> [M]any things .. are .. inappropriate for some machines, and the standard
> should not mandate their existence, but there is no reason [not to] say
> something about them.
>
> 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.
> 
> There are many such instances where something that would be useful in some
> implementations has been omitted from the standard because it cannot
> reasonably be required in all implementations.  This means that each
> individual implementation that wants such a feature is going to have to
> invent its own method (as the standard allows), and that many of these
> implementations will be needlessly different.

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.

Frankly, I think it's time for us to crush this anti-standard bias once and
for all by simply adopting a level playing field that clearly recognizes and
_respects_ the existence of various well-known standards and does not
unnecessarily avert the appropriate penalties for willfully ignoring them.

If this "standard" will not address such things then there ought to be a
supplementary standard written by and for those who follow such standards to
specify compliance with those standards for implementors of this standard.

Lum Johnson  lum at ohio-state.arpa  ..!cbosgd!osu-eddie!lum

Enufk is enufk - that's all I can takes, I can't takes no more. - Popeye



More information about the Comp.lang.c mailing list