minow@decvax.UUCP (Martin Minow) (12/14/86)
This is one of a collection of comments on the Draft Standard, posted to comp.lang.c for discussion before I mail a final draft to the Ansi C committee. Each message discusses one problem I have found with the Draft Standard that I feel warrants a "no" vote. Note that this message is my personal opinion, and does not reflect on the opinions of my employer. ---- Problem: Page 13, line 10ff (and many other places). The values defined in <limits.h> should be written with a leading underscore, so they do not occupy the name space reserved to user programs. The Standard should not create new quasi-reserved words that occupy the name space reserved to user programs. ---- Motivation: Page 13, line 10ff (and many other places). As discussed in section 4 (page 84, line 26), all identifiers and macro names that begin with an underscore are reserved to the implementation. The Standard has also defined several hundred macros, typedefs, and symbolic constants with initial alphabetic characters. This results in a situation where the programmer cannot easily define variables that are guaranteed never to conflict with implementation reserved words. Except for those few reserved words in current common usage (such as NULL), all implementation defined macros and data types should be defined with an initial underscore. This will offer a clear indication to the programmer that an implementation specific value or function is being used. It will also guarantee that future standards can define additional macros without breaking existing programs. ---- Martin Minow decvax!minow
gwyn@brl-smoke.ARPA (Doug Gwyn ) (12/15/86)
In article <107@decvax.UUCP> minow@decvax.UUCP (Martin Minow) writes: >Page 13, line 10ff (and many other places). The values defined in ><limits.h> should be written with a leading underscore, so they do not >occupy the name space reserved to user programs. This is a good idea that has been discussed and rejected by the committee already, primarily on the grounds of conflict with existing practice (/usr/group and IEEE 1003.1), if I remember correctly. Therefore, your best bet to get this proposal approved is to find an X3J11 member who is willing to present it personally, so that you don't just get an "already considered and rejected" response. (I'm not volunteering, however!) This applies to any issue that you feel very strongly about.
meissner@dg_rtp.UUCP (Michael Meissner) (12/26/86)
In article <107@decvax.UUCP> minow@decvax.UUCP (Martin Minow) writes: > > Page 13, line 10ff (and many other places). The values defined in > <limits.h> should be written with a leading underscore, so they do not > occupy the name space reserved to user programs. The Standard should not > create new quasi-reserved words that occupy the name space reserved to > user programs. The reasons the names in limits.h are what they are, is we started with with 1984 /usr/group document as the base document for the library section. I believe the reason /usr/group chose the names they did was to accomidate preprocessors with 8 characters of significance. At the last meeting (which was also the P1003 meeting in the same hotel) it was brought up to P1003 (the offical successors to the /usr/group document). -- Michael Meissner, Data General ...mcnc!rti-sel!dg_rtp!meissner