ANSI C -- non-required features.

[Ray Butterworth]

In article <5458 at brl-smoke.ARPA>, gwyn at brl-smoke.ARPA (Doug Gwyn ) writes:
> >The standard should specify the internal representations
> >for the predefined 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.
> 
> >Page 91, line 46ff. Note that, in a Latin 1 environment, the ispunct() and
> >isspace() functions should test for the non-breaking space at 0xA0.
> No particular character set is required, so we can't make such
> remarks in the standard itself.  Perhaps the Rationale should
> give such examples.
> 
> A lot of proposals for new features have been rejected in an
> attempt to keep the size of the language and its environment
> relatively small.  (This attempt hasn't been totally successful,
> but it's certainly a worthwhile goal.)  Therefore, please don't
> interpret failure to adopt a suggestion as necessarily implying
> that there is something wrong with the idea, although often
> there is (in which case the response should point out what).

One of my biggest gripes with the proposed standard is the things
it deliberately doesn't describe.  Certainly there are many things
that are totally inappropriate for some machines, and the standard
should not mandate their existence, but there is no reason that the
standard can't at least say something about them.

Let's take a trivial example.  The committee has refused to define
"\e" as the string escape sequence for the ASCII character ESC
on the grounds that many implementations (i.e. IBM) won't be using
ASCII and so this would be impossible for them to implement.
That is certainly true.  But it's no reason for not putting into
the standard something of the form "for implementations using the
ASCII character set, '\e' will be the ESC character".  Similarly
the standard could define 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 would really like to see, either directly in the document itself,
or as an appendix, descriptions of such non-required extensions.
The Rationale is not the place for it (I don't believe that the
Rationale will be published as an official part of the final
standard will it?).  Since they are optional features, this won't
affect those compilers that can't reasonably implement them, but
for the others it will greatly simplify things and make programs
that much more portable (isn't that what this standard is supposed
to be for in the first place?).