prc@maxim.ERBE.SE (Robert Claeson) (03/16/89)
How long can local (to the file) and external identifiers be in ANSI C?
And will POSIX specify an other identifier length?
--
Robert Claeson, ERBE DATA AB, P.O. Box 77, S-175 22 Jarfalla, Sweden
Tel: +46 (0)758-202 50 Fax: +46 (0)758-197 20
EUnet: rclaeson@ERBE.SE uucp: {uunet,enea}!erbe.se!rclaeson
ARPAnet: rclaeson%ERBE.SE@uunet.UU.NET BITNET: rclaeson@ERBE.SEprc@maxim.ERBE.SE (Robert Claeson) (03/16/89)
I tried to, but was unable to cancel my previous artice (I *know* that I should use the 'c' key in vnews -- I did that and it just told me "Can't cancel what you didn't write"). In article <627@maxim.ERBE.SE>, I wrote: > How long can local (to the file) and external identifiers be in ANSI C? > And will POSIX specify an other identifier length? What I'm asking for in this terse, cryptic manner is the maximum number of characters that an identifier can have in pure ANSI C and ANSI C in a POSIX environment, respectively. I'm ANSIfying some software and don't want to shrink my looong, beautiful names more than neccesary. -- Robert Claeson, ERBE DATA AB, P.O. Box 77, S-175 22 Jarfalla, Sweden Tel: +46 (0)758-202 50 Fax: +46 (0)758-197 20 EUnet: rclaeson@ERBE.SE uucp: {uunet,enea}!erbe.se!rclaeson ARPAnet: rclaeson%ERBE.SE@uunet.UU.NET BITNET: rclaeson@ERBE.SE
henry@utzoo.uucp (Henry Spencer) (03/17/89)
In article <627@maxim.ERBE.SE> prc@maxim.ERBE.SE (Robert Claeson) writes: >How long can local (to the file) and external identifiers be in ANSI C? There is no limit on identifier length. However, implementations are permitted to consider only the first N characters significant. For internal names, N must be at least 31 and upper and lower case must be distinct. For external names, the need to work with existing linkers limits what ANSI can insist on: N must be at least 6, and distinctions of case can be ignored. The Rationale comments: "...strong sentiment was expressed for making C ``right'' by requiring longer names everywhere... This is unacceptable since the whole reason for a standard is portability, and many systems today simply do not provide such a name space..." -- Welcome to Mars! Your | Henry Spencer at U of Toronto Zoology passport and visa, comrade? | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
dhesi@bsu-cs.UUCP (Rahul Dhesi) (03/17/89)
In article <1989Mar16.171213.21210@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >The Rationale comments: "...strong sentiment >was expressed for making C ``right'' by requiring longer names everywhere... >This is unacceptable since the whole reason for a standard is portability, >and many systems today simply do not provide such a name space..." ^ The 6-character limit is water under the bridge and complaining about it now won't change it, so I won't do that. I do object to the above reasoning, because it implies something incorrect. I've described in the past how simple it is for a C implementation to overcome the 6-character limit of existing linkers without changing the linker. If the programmer can think of a name like "get_time_of_day" and mentally convert it to "gettod" without creating a conflict, surely an implementation of C can do the same. 1. The C compiler generates object files containing long external identifiers when needed. It extends the object file format to accommodate these identifiers. 2. A pre-linker scans all object files. Those that contain no long identifiers are already ready for the system linker. In those that contain long names, it converts the long long names to short ones, and generates code ready for linking with the standard system linker. In each generated short name it adds a special character that never occurs in the name of any library routine. Or it recognizes everything in the ANSI standard libraries and system-specific libraries and avoids generating a conflicting name. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi ARPA: dhesi@bsu-cs.bsu.edu
henry@utzoo.uucp (Henry Spencer) (03/18/89)
In article <6161@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >I've described in the past how simple it is for a C implementation to >overcome the 6-character limit of existing linkers without changing the >linker. If the programmer can think of a name like "get_time_of_day" >and mentally convert it to "gettod" without creating a conflict, surely >an implementation of C can do the same. The Rationale says: "This option [identifier mapping] quickly becomes very complex for large, multi-source programs, since a program-wide database has to be maintained for all modules to avoid giving two different identifiers the same actual external name. It also reduces the usefulness of source code debuggers and cross reference programs, which generally work with the short mapped names, since the source-code name used by the programmer would likely bear little resemblance to the name actually generated..." (The first part is obviously thinking about doing it as part of the compiler, not as a pre-linking pass.) Rahul, did you propose your notion to X3J11? Formally, I mean, not just by talking about it on the net? If so, what was the response? If not, why not? -- Welcome to Mars! Your | Henry Spencer at U of Toronto Zoology passport and visa, comrade? | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
dhesi@bsu-cs.UUCP (Rahul Dhesi) (03/19/89)
In article <1989Mar17.175939.1226@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes (about the 6-char limit and how to overcome it): >Rahul, did you propose your notion to X3J11? Formally, I mean, not just >by talking about it on the net? If so, what was the response? If not, >why not? A good question. I wrote my first "hello world" program in 1986, and didn't know much about the real world of C until much more recently. I didn't discover Duff's Device and other tricky stuff until a year ago. I didn't even consider proposing something because I assumed I would have been laughed at for some obvious error on my part about which I should have known better. I sincerely doubt that I would have made a difference. This was a political issue. Another one was refusal to standardize the common practice of 0=normal, nonzero=error in exit(n), which requires a but a one-line supporting function in the runtime library: exit(n) { _vms_c_exit ( n ? SYS$_ABORT : SYS$_NORMAL); } Dont mistake this for a flame. There may be political glitches in the standard, but it represents a lot of hard work done well. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi ARPA: dhesi@bsu-cs.bsu.edu
daveb@geaclib.UUCP (David Collier-Brown) (03/19/89)
In article <1989Mar16.171213.21210@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: | The Rationale comments: "...strong sentiment | was expressed for making C ``right'' by requiring longer names everywhere... | This is unacceptable since the whole reason for a standard is portability, | and many systems today simply do not provide such a name space..." ^ From article <6161@bsu-cs.UUCP>, by dhesi@bsu-cs.UUCP (Rahul Dhesi): | The 6-character limit is water under the bridge and complaining about | it now won't change it, so I won't do that. I do object to the above | reasoning, because it implies something incorrect. [ discussion of several shortening techniques] At this point I usually detail a scheme for upgrading one's linker. (Sorry, its on the verge of being a knee-jerk reaction...) I'll refrain this time and point out that companies expecting to sell computers to the U.S. and perhaps Canadian government have reason to extend their linkers to meet the requirements for structured name spaces sufficient to support Ada [tm, betimes]. Given that precious experience is a consideration in these standardization efforts, would someone care to comment on the **in**advisability of extending the minimum external identifier length as of the next standardization of the C language. --dave c-b [ps: no, that last paragraph wasn't an insult. I reserve them for comp.lang.c and people other than Rahul & Henry] -- David Collier-Brown. | yunexus!lethe!dave Interleaf Canada Inc. | 1550 Enterprise Rd. | He's so smart he's dumb. Mississauga, Ontario | --Joyce C-B
henry@utzoo.uucp (Henry Spencer) (03/19/89)
In article <6212@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >I didn't even consider proposing something because I assumed I would >have been laughed at for some obvious error on my part about which I >should have known better. I assure you, standards committees see lots of *really* dumb ideas, and are seldom known to laugh at them. (Sighs of resignation are rather more common -- people who've never tried it have no idea how much paper a standards committee has to wade through, and how many times they get to see the same ideas.) No idea which is at least superficially reasonable will be ignored or laughed at. But it is inherently impossible for a standards committee to consider ideas that people don't feel strongly enough about to submit. >I sincerely doubt that I would have made a difference. This was a >political issue... Unfortunately, standards are useless without acceptance by the Big Boys, and this makes politics inevitable. However, I think you are doing people a serious injustice by implying that everyone who favored the six-character restriction was politically motivated. Not so. Many people did indeed feel exactly what the Rationale says: the restriction is unpleasant but it is a recognition of reality -- there is no practical way around it that preserves real-world portability and usability today. -- Welcome to Mars! Your | Henry Spencer at U of Toronto Zoology passport and visa, comrade? | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
mark@jhereg.Jhereg.MN.ORG (Mark H. Colburn) (03/21/89)
In article <3780@geaclib.UUCP> daveb@geaclib.UUCP (David Collier-Brown) writes: > At this point I usually detail a scheme for upgrading one's linker. >(Sorry, its on the verge of being a knee-jerk reaction...) I'll >refrain this time and point out that companies expecting to sell >computers to the U.S. and perhaps Canadian government have reason to >extend their linkers to meet the requirements for structured name >spaces sufficient to support Ada [tm, betimes]. This tends to be my reaction too. However, there are some companies which do not want to touch their linkers. Some of these, because their current linker works, and fixing it might mean breaking it. Others, as has been pointed out before, may not even have the source code to their linkers to upgrade them. It is a sad state of affairs, to be sure. Here we are, heading into the 1990's, still using 1960's technology for some things. It's a shame, but it's true. Concesions to reality. > Given that precious experience is a consideration in these >standardization efforts, would someone care to comment on the >**in**advisability of extending the minimum external identifier >length as of the next standardization of the C language. It would most likely depend on the feeling of the working group at the time of the next standard. It may well be that some of the "Big Boys" as Henry called them, may have upgraded their linkers by then, and if so, they may be willing to drop the 6 character name limit. I hope so. Along the same lines, there are some problems with read and write that should probably be cleared up as well. The current dPS says that writing to an existing file may cause it to be truncated beyond the point that the file was written. This make things like writing a data-base difficult to do as a "strictly conforming application". The comment that I got back from the working group was that this behavior was required by some systems. The standards group is trying to get the language availale for the widest variety of computers and operating systems that they can. I can appreciate the effort and the compromises required to achieve that goal, being on a standards committee myself. I don't agree with all of the decisions made by X3J11, but I am sure that they did as good a job as they (or anybody else) could given the diverse systems which they had to support. -- Mark H. Colburn "Look into a child's eye; Minnetech Consulting, Inc. there's no hate and there's no lie; mark@jhereg.mn.org there's no black and there's no white."