Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!brl-adm!rutgers!clyde!watmath!rbutterworth From: rbutterworth@watmath.UUCP (Ray Butterworth) Newsgroups: comp.lang.c Subject: ANSI C -- non-required features. Message-ID: <3987@watmath.UUCP> Date: Wed, 17-Dec-86 11:25:51 EST Article-I.D.: watmath.3987 Posted: Wed Dec 17 11:25:51 1986 Date-Received: Thu, 18-Dec-86 04:36:33 EST References: <112@decvax.UUCP> <5458@brl-smoke.ARPA> Organization: U of Waterloo, Ontario Lines: 53 In article <5458@brl-smoke.ARPA>, gwyn@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?).