ka@cbnewsh.ATT.COM (Kenneth Almquist) (06/21/89)
karl@haddock.ima.isc.com (Karl Heuer) writes: > Technically this is illegal because the str* namespace is reserved... I know that ANSI C reserves all names that begin with and underscore, and I just learned from the above quote that it reserves all names beginning with "str". Are there other names to be avoided as well? Kenneth Almquist
bill@twwells.com (T. William Wells) (06/21/89)
In article <1598@cbnewsh.ATT.COM> ka@hulk.att.com writes: : karl@haddock.ima.isc.com (Karl Heuer) writes: : > Technically this is illegal because the str* namespace is reserved... : : I know that ANSI C reserves all names that begin with and underscore, : and I just learned from the above quote that it reserves all names : beginning with "str". Are there other names to be avoided as well? Yes. From reading section 4.13: E[0-9A-Z].* macros in errno.h is[a-z].* externals, ctype.h to[a-z].* externals, ctype.h LC_[A-Z].* macros in locale.h <func>f <func> is any function defined in math.h <func>l <func> is any function defined in math.h SIG[A-Z].* macros in signal.h SIG_[A-Z].* macros in signal.h str[a-z].* externals, stdlib.h and string.h mem[a-z].* externals, string.h wcs[a-z].* externals, string.h No doubt there are others scattered throughout the spec, but I haven't the will to go hunting for them. Can you say "name space pollution"? Good! --- Bill { uunet | novavax | ankh | sunvice } !twwells!bill bill@twwells.com
dfp@cbnewsl.ATT.COM (david.f.prosser) (06/21/89)
In article <1598@cbnewsh.ATT.COM> ka@hulk.att.com writes: >karl@haddock.ima.isc.com (Karl Heuer) writes: >> Technically this is illegal because the str* namespace is reserved... > >I know that ANSI C reserves all names that begin with and underscore, >and I just learned from the above quote that it reserves all names >beginning with "str". Are there other names to be avoided as well? > Kenneth Almquist Section 4.1.2.1 of the pANS goes into some detail about what is reserved in varying circumstances, but the best rule of thumb is to keep away from names that begin with _ and remember that the following patterns (egrep-type meta-characters) are also reserved: <errno.h> macros E[0-9A-Z][_0-9a-zA-Z]* <ctype.h> functions (is|to)[a-z][_0-9a-zA-Z]* <locale.h> macros LC_[A-Z][_0-9a-zA-Z]* <math.h> functions "existing functions"[fl] <signal.h> macros (SIG|SIG_)[A-Z][_0-9a-zA-Z]* <stdlib.h> functions str[a-z][_0-9a-zA-Z]* <string.h> functions (str|mem|wcs)[a-z][_0-9a-zA-Z]* Dave Prosser ...not an official X3J11 answer...
minow@mountn.dec.com (Martin Minow) (06/22/89)
Kenneth Almquist asks what namespace is reserved by Ansi C. Several people responded with various lexical patterns. Unfortunately, none of the Drafts I've seen ever specified the totality of the namespace. We know that the C keywords and anything beginning with underscore are reserved, but there does not seem to be a limit on the library namespace. When I complained about this in one of the public reviews, I was told that this was for "Posix compliance." I suspect that the namespace will continue to grow without bound, and the best you can do to avoid polluting (or being polluted) is to define all of your variables using some "private" initial sequence: extern int my_private_global_foo; static int my_private_local_bar; (I have much the same problem on the Macintosh, and define all of my variables in lower-case with an embedded underscore to avoid Macintosh system definitions, most of which use mixed case without underscores.) Martin Minow minow%thundr.dec@decwrl.dec.com The above does not represent the position of Digital Equipment Corporation.
gwyn@smoke.BRL.MIL (Doug Gwyn) (06/22/89)
In article <1989Jun21.090428.9636@twwells.com> bill@twwells.com (T. William Wells) writes: > E[0-9A-Z].* macros in errno.h > is[a-z].* externals, ctype.h > to[a-z].* externals, ctype.h > LC_[A-Z].* macros in locale.h > <func>f <func> is any function defined in math.h > <func>l <func> is any function defined in math.h > SIG[A-Z].* macros in signal.h > SIG_[A-Z].* macros in signal.h > str[a-z].* externals, stdlib.h and string.h > mem[a-z].* externals, string.h > wcs[a-z].* externals, string.h The E* names are reserved only if <errno.h> is included. Similarly, the LC_* names are reserved only if <locale.h> is included, and SIG* names are reserved only if <signal.h> is included. The function names mentioned are (of necessity) reserved whether or not headers are included. >No doubt there are others scattered throughout the spec, but I >haven't the will to go hunting for them. No doubt? Section 4.1.2.1 covers this issue; it mentions the 4.13 sections, _* names, etc. "No other identifiers are reserved." >Can you say "name space pollution"? X3J11 didn't cause C name space pollution; to the contrary, it has finally been brought under control. The majority of the above name classes were already "polluted" by existing practice, so they were identified and the existing practice allowed to continue but within the newly established limits. Certainly, application developers need to know these limits so they can stay on the other side of the fence. At least they have now been allowed to stake out territory of their own. If one were designing a C-like language from scratch today, in the light of past experience it would be wise to introduce some sort of "package" concept and adhere strictly to it.
decot@hpisod2.HP.COM (Dave Decot) (06/22/89)
> Yes. From reading section 4.13: > > E[0-9A-Z].* macros in errno.h > is[a-z].* externals, ctype.h > to[a-z].* externals, ctype.h > LC_[A-Z].* macros in locale.h > <func>f <func> is any function defined in math.h > <func>l <func> is any function defined in math.h > SIG[A-Z].* macros in signal.h > SIG_[A-Z].* macros in signal.h > str[a-z].* externals, stdlib.h and string.h > mem[a-z].* externals, string.h > wcs[a-z].* externals, string.h These do not really benefit the implementation either, because the (draft) standard requires so many other things to be hidden from the application's namespace the extra effort to hide such names is less than that of documenting that the application can't use them. Sigh. Dave
diamond@diamond.csl.sony.junet (Norman Diamond) (06/22/89)
In article <1989Jun21.090428.9636@twwells.com> bill@twwells.com (T. William Wells) writes: > is[a-z].* externals, ctype.h Geez. Last time I wrote a C program, guess how I named all my boolean predicates. There's a lesson here: on those rare occasions when Unix provides an example of good style, don't you dare learn from it. (Partially thanks to Global Engineering Documents, who refused to sell a public review copy of the draft standard.) >Can you say "name space pollution"? Yup. Maybe, in order to standardize existing practice, no user-defined identifiers may start with an alphabetic. They must ALL start with an underscore followed by a lower-case letter. -- Norman Diamond, Sony Computer Science Lab (diamond%csl.sony.jp@relay.cs.net) The above opinions are claimed by your machine's init process (pid 1), after being disowned and orphaned. However, if you see this at Waterloo, Stanford, or Anterior, then their administrators must have approved of these opinions.
gwyn@smoke.BRL.MIL (Doug Gwyn) (06/22/89)
In article <1598@cbnewsh.ATT.COM> ka@hulk.att.com writes: >I know that ANSI C reserves all names that begin with and underscore, >and I just learned from the above quote that it reserves all names >beginning with "str". Are there other names to be avoided as well? Not all names beginning with underscore are reserved; for example, applications may use structure members named e.g. _hidden. Similarly, it is only external names for which the str prefix is reserved (for future standardization). There are several name spaces in C, and reserved names usually are restricted to a subset of the totality of name spaces. A complete list should be given in any book proclaiming "ANSI C" on its cover, of which there are several.
dfp@cbnewsl.ATT.COM (david.f.prosser) (06/22/89)
In article <316@mountn.dec.com> minow%thundr.dec@decwrl.dec.com (Martin Minow) writes: >Kenneth Almquist asks what namespace is reserved by Ansi C. > >Several people responded with various lexical patterns. Unfortunately, >none of the Drafts I've seen ever specified the totality of the namespace. If it isn't reserved in the pANS, then it's not reserved. Period. Thus, by definition, the "totality" of the reserved namespace is specified. >We know that the C keywords and anything beginning with underscore are >reserved, but there does not seem to be a limit on the library namespace. There is a fixed set of names and some extension patterns based on the names already included by that header. This is clearly based on existing practice. >When I complained about this in one of the public reviews, I was told that >this was for "Posix compliance." I don't know what particular item you are referring to here, and the answer of "Posix compliance" cannot by itself be an X3J11 motivation. > >I suspect that the namespace will continue to grow without bound, and the >best you can do to avoid polluting (or being polluted) is to define all >of your variables using some "private" initial sequence: > > extern int my_private_global_foo; > static int my_private_local_bar; > >(I have much the same problem on the Macintosh, and define all of my >variables in lower-case with an embedded underscore to avoid Macintosh >system definitions, most of which use mixed case without underscores.) This may well be a reasonable approach. Despite X3J11's best efforts to control the namespace, most vendors will continue to pollute the programmers' namespace. X3J11 found itself in a fairly painful position on this issue: Half the comments on the namespace were of the "X3J11 has reserved more names than COBOL--what's going on here!?" variety and the other half were "X3J11 has made it impossible to implement <whatever> due to its overly restrictive namespace--remove these silly limits!" What X3J11 has successfully done is made it possible to write useful C programs that require not a single character to be changed to compile and run on every hosted ANSI C conforming implementation. Without the fixed limits on namespace, this would never have been possible. Moreover, the pANS also provides enough escape clauses to allow implementations the freedom necessary to provide their extensions. Of course, in some cases, the job is a little difficult for both types of X3J11 users--this is a natural result of walking the middle ground. > >Martin Minow >minow%thundr.dec@decwrl.dec.com >The above does not represent the position of Digital Equipment Corporation. Dave Prosser ...not an official X3J11 answer...
minow@mountn.dec.com (Martin Minow) (06/23/89)
In article <884@cbnewsl.ATT.COM> dfp@cbnewsl.ATT.COM (david.f.prosser) writes: > >>When I complained about this in one of the public reviews, I was told that >>this was for "Posix compliance." ["this" refers to namespace pollution"] > >I don't know what particular item you are referring to here, and the answer >of "Posix compliance" cannot by itself be an X3J11 motivation. From X3J11/87-207, page 17 (responses to first public comments): Summary of issues: Add leading underscores to names in <limits.h> Committee Response: This proposal would invalidate too much existing source code. Many of these names were chosen to agree with other standards. Despite a number of comments on this issue, the Committee stands by its decision to adhere to the names specified in both the /usr/group Standard and IEEE Std 1003.1 (POSIX). ------ The committee *could* have defined all library names using leading underscores and included a suggestion that vendors supply a <posix.h> or similar to map Ansi names into "existing practice." (This may also solve the 6-character monospace problem). I continue to have difficulty writing transportable programs when well-meaning implementors use useful words (such as "line" in one vendor's Macintosh C library). Since there is only one Ansi Standard and, hopefully, many people writing code to that standard, I wish the Committee had found way to prevent the C-implementation namespace from growing without bounds. Martin Minow minow%thundr.dec@decwrl.dec.com
gwyn@smoke.BRL.MIL (Doug Gwyn) (06/23/89)
In article <321@mountn.dec.com> minow@mountn.UUCP (Martin Minow) writes: >I continue to have difficulty writing transportable programs when well-meaning >implementors use useful words (such as "line" in one vendor's Macintosh >C library). Since there is only one Ansi Standard and, hopefully, many >people writing code to that standard, I wish the Committee had found >way to prevent the C-implementation namespace from growing without bounds. But the proposed Standard does address this issue. To take your example of <limits.h>, non-underscore stuff beyond that specified in the Standard is not permitted to be defined by <limits.h> in a standard-conforming C implementation. The Standard imposes definite bounds on name space pollution; as Dave noted, this is a unique achievement.
dfp@cbnewsl.ATT.COM (david.f.prosser) (06/26/89)
In article <321@mountn.dec.com> minow@mountn.UUCP (Martin Minow) writes: >In article <884@cbnewsl.ATT.COM> dfp@cbnewsl.ATT.COM (david.f.prosser) writes: >> >>>When I complained about this in one of the public reviews, I was told that >>>this was for "Posix compliance." >["this" refers to namespace pollution"] >> >>I don't know what particular item you are referring to here, and the answer >>of "Posix compliance" cannot by itself be an X3J11 motivation. > >From X3J11/87-207, page 17 (responses to first public comments): > > Summary of issues: Add leading underscores to names in <limits.h> > > Committee Response: This proposal would invalidate too much existing > source code. > > Many of these names were chosen to agree with other standards. Despite > a number of comments on this issue, the Committee stands by its decision > to adhere to the names specified in both the /usr/group Standard and > IEEE Std 1003.1 (POSIX). > >------ Note that this does not state that these names were chosen for POSIX conformance, but that these names were based on existing implementations, and in the interests of existing code. The same motivations were present for both /usr/group and POSIX, so the name choices were made, where ever possible, to agree with other (to be) standards. > >The committee *could* have defined all library names using leading >underscores and included a suggestion that vendors supply a <posix.h> >or similar to map Ansi names into "existing practice." (This may also >solve the 6-character monospace problem). Yes, the Committee *could* have done so, but then they would have been clearly in violation of its "codify existing practice" foundation. The above proposal to rename the existing names in <limits.h> with a leading underscrore would have, in practice, only *increased* the number of reserved names! Since *all* current implementations would need to add an entire set of new names, and since they could not cause their customers' code to fail to compile, all the old names would need to be still available. Requiring even the inclusion of a new header would have been unworkable. Moreover, any program that wanted to work with both old and new compilers would be, at best, only slightly unreadable since for every library function, there would need to be some macro version to map the name between one version or another. The Committee received a number of similar requests. In a *perfect* world, there would have been no doubt that the Committee would have caused the set of reserved names to be obviously distinct from programmer-defined names, but the years of existing practice made that approach impossible. What the Committee did was come to a workable compromise: Implementations are required to prevent any names other than those that are standardized to be forced on a strictly conforming program while programmers need to remember that certain names are reserved. The programmer's job is not as bad as one makes it out to be since a program's use of a reserved name (that works) on a particular implementation still produces a conforming program. It is only those programs striving for strict conformance that must be especially careful. This is not an attempt to say that programmers should not try for strict conformance, but just an acknowledgement that most programs happen to rely on nonportable features or nonstandard library functions. > >Martin Minow >minow%thundr.dec@decwrl.dec.com Dave Prosser ...not an official X3J11 answer...
minow@mountn.dec.com (Martin Minow) (06/27/89)
If the problem were only limits.h, or only stdio.h, or only ctype.h, there would be no objection, but the library is, in reality, a monolith of a dozen or so packages with a total of several hundred names, with a variety of syntactic patterns. I shouldn't be expected to memorize all these names or their syntactic patterns. The application environment has gotten steadily more complex in the ten or twelve years since C left its original home. I see nothing to suggest that the environment will become simpler (indeed, quite the opposite). I wish that, along with reserving a wide variety of lexical patterns to Ansi, some set of patterns were reserved to application programs. For example, on VMS, XXX$<anything> is explicitly reserved to VMS development (and a development group must reserve its private XXX header), while XXX_<anything> is explicitly reserved to user development. As a software architect, one of my primary tasks is managing complexity. If, for example, ANSI reserves <letters> '__' <letters-or-digits> to application programs, I could write standard-conforming programs without worrying that version 2, 3, or whatever of the standard conflicted with my code. Martin Minow minow%thundr.dec@decwrl.dec.com The above does not represent the position of Digital Equipment Corporation.
prc@erbe.se (Robert Claeson) (06/28/89)
In article <362@mountn.dec.com> minow%thundr.dec@decwrl.dec.com (Martin Minow) writes: >For example, on VMS, XXX$<anything> is explicitly reserved to VMS >development (and a development group must reserve its private XXX header), >while XXX_<anything> is explicitly reserved to user development. >If, for example, ANSI reserves <letters> '__' <letters-or-digits> to >application programs, I could write standard-conforming programs without >worrying that version 2, 3, or whatever of the standard conflicted with >my code. Sure, that would be nice, but with 6 (or was it 8?) character external identifiers, you won't have much luck in finding readable names... i n e w s -- Robert Claeson E-mail: rclaeson@erbe.se ERBE DATA AB
dfp@cbnewsl.ATT.COM (david.f.prosser) (07/01/89)
In article <362@mountn.dec.com> minow%thundr.dec@decwrl.dec.com (Martin Minow) writes: >If the problem were only limits.h, or only stdio.h, or only ctype.h, >there would be no objection, but the library is, in reality, a monolith >of a dozen or so packages with a total of several hundred names, with a >variety of syntactic patterns. I shouldn't be expected to memorize >all these names or their syntactic patterns. We all sympathize with your point here, and you're right at least for me: I need to go back and check in certain situations since the rules are pretty complex and some of the patterns not simple...the worst is the <math.h> reservations since one has to know all the names of the functions in <math.h> before the reserved name space is known. > >The application environment has gotten steadily more complex in the >ten or twelve years since C left its original home. I see nothing to >suggest that the environment will become simpler (indeed, quite the >opposite). Quite correct. The growing complexity was what served as X3J11's existing practice... > >I wish that, along with reserving a wide variety of lexical patterns >to Ansi, some set of patterns were reserved to application programs. >For example, on VMS, XXX$<anything> is explicitly reserved to VMS >development (and a development group must reserve its private XXX header), >while XXX_<anything> is explicitly reserved to user development. Pretty much the entire Committee probably wishes something along these lines. It's not that I disagree with your points, it's just that the existing implementations govern what gets standardized. There was just no way for X3J11 to do any better than it did. With the exception of the few new library functions introduced by X3J11 (such as those for multiple locale and multibyte character handling), every name noted as reserved was already "reserved" in the existing C world. X3J11 made things better, actually, since it "put on the breaks" as soon as it could. > >As a software architect, one of my primary tasks is managing complexity. >If, for example, ANSI reserves <letters> '__' <letters-or-digits> to >application programs, I could write standard-conforming programs without >worrying that version 2, 3, or whatever of the standard conflicted with >my code. For the most part, there is are some simple rules that you can use to prevent your conflicting with the reserved name space: If you write all your file scope and external linkage names with at least one underscore as the second, third, or fourth character, but not the first, you'll be in good shape. This rule doesn't help with macros in general, but since macros are only reserved when their respective header is included, keeping track of macros is easier. > >Martin Minow >minow%thundr.dec@decwrl.dec.com >The above does not represent the position of Digital Equipment Corporation. Dave Prosser ...not an official X3J11 answer...
jeffrey@algor2.UUCP (Jeffrey Kegler) (07/02/89)
In article <321@mountn.dec.com> minow@mountn.UUCP (Martin Minow) writes: >I continue to have difficulty writing transportable programs when well-meaning >implementors use useful words (such as "line" in one vendor's Macintosh >C library). Since there is only one Ansi Standard and, hopefully, many >people writing code to that standard, I wish the Committee had found >way to prevent the C-implementation namespace from growing without bounds. We have a number of worthwhile but conflicting goals involved here. 1) All libraries should use nice, easy to remember names. 2) No libraries should use any name any application programmer might want to use. (Presumably this includes all the nice, easy to remember ones.) 3) No library should use a name another library is likely to use. (That is, you are telling the library programmer, "Quick, think of 130 names nobody else will ever think of") 4) All external names must be distinct, case distinctions not included, in the first 6 characters, in order to be fully portable. Whose linker was this, anyway, that we are going to spend the next two decades wrecking our code for? (Couldn't the ANSI C committee have found a linker somewhere that was restricted to 5 characters, vowels not counted?) :-) The only real solution to this problem is something like the renaming facility that was allowed in ADA. That is, suppose you are using one person's window manager library, and the patented WhatchaMacallit database. Both use names all carefully prefixed with WM_ to prevent conflicts. The only way to prevent conflicts like this is to license library writers, which solution is far worse than than (admittedly nasty) problem. And here both library writers have tried to be careful, at the expense of readability. They left themselves exactly three characters in which their external names must be distinct. (They could try numbering them, WM_000, WM_001, etc.) :-) The renaming could be implemented as a utility that mungs object files (semi-portable), or as an input file to the loader (completely unportable) or via pragmas (completely unportable). Or a utility could be written to convert programs to strictly conforming ones (portable, very ugly, and a nasty thing to do to the guy who will have to work with the munged variable names). -- Jeffrey Kegler, President, Algorists, jeffrey@algor2.UU.NET or uunet!algor2!jeffrey 1762 Wainwright DR, Reston VA 22090
henry@utzoo.uucp (Henry Spencer) (07/02/89)
In article <461@algor2.UUCP> jeffrey@algor2.UUCP (Jeffrey Kegler) writes: >Whose linker was this, anyway, that we are going to spend the next two >decades wrecking our code for? Any linker that supports the bare minimum for FORTRAN. There are more such linkers in the world than you'd think. > (Couldn't the ANSI C committee have >found a linker somewhere that was restricted to 5 characters... Can you say "Data General"? I knew you could! :-) Fortunately, as I understand it, even DG agreed that this was DG's mistake, and nobody seriously suggested munging the standard to match. -- $10 million equals 18 PM | Henry Spencer at U of Toronto Zoology (Pentagon-Minutes). -Tom Neff | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
bph@buengc.BU.EDU (Blair P. Houghton) (07/03/89)
In article <1989Jul1.234330.28732@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >In article <461@algor2.UUCP> jeffrey@algor2.UUCP (Jeffrey Kegler) writes: >>Whose linker was this, anyway, that we are going to spend the next two >>decades wrecking our code for? > >Any linker that supports the bare minimum for FORTRAN. There are more >such linkers in the world than you'd think. Which begs the question: how difficult is it to have standard-conforming implementations implement a linker that handles a larger name space? (Yeah, I know. C is not a linker, so the linker is beyond the scope of the standard. So, too, was once the library...) Corrollarily, ("corrollarily"? :) how hard is it to increase the external identifier size allowed by a linker? (Actually, it should have been "lemmatically," but the chronology is bass-ackwards...) >> (Couldn't the ANSI C committee have >>found a linker somewhere that was restricted to 5 characters... > >Can you say "Data General"? I knew you could! :-) Say it? I can SEE it, if I walk downstairs. --Blair "Although it's been a long time since the DG has seen mobile electrons, apparently..."
henry@utzoo.uucp (Henry Spencer) (07/03/89)
In article <3364@buengc.BU.EDU> bph@buengc.bu.edu (Blair P. Houghton) writes: >>Any linker that supports the bare minimum for FORTRAN. There are more >>such linkers in the world than you'd think. > >Which begs the question: how difficult is it to have standard-conforming >implementations implement a linker that handles a larger name space? Potentially very difficult if you have to convince the supplier to support two different object-module formats. Please, folks, let us not get into a long debate about this one again. The facts are: 1. Some suppliers are not willing to do it immediately. 2. X3J11 is not in the business of legislating morality; its job is to produce a standard that will be accepted and followed widely. In the real world, this sometimes requires temporary concessions to badly-designed but widespread existing software. 3. This particular concession *is* temporary; the draft standard contains an explicit warning that it is likely to go away in future. -- $10 million equals 18 PM | Henry Spencer at U of Toronto Zoology (Pentagon-Minutes). -Tom Neff | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
diamond@diamond.csl.sony.junet (Norman Diamond) (07/06/89)
In article <461@algor2.UUCP> jeffrey@algor2.UUCP (Jeffrey Kegler) writes: >The only real solution to this problem is something like the renaming >facility that was allowed in ADA. (Ada and a few other languages.) >That is, suppose you are using one >person's window manager library, and the patented WhatchaMacallit >database. Both use names all carefully prefixed with WM_ to prevent >conflicts. The only way to prevent conflicts like this is to license >library writers, which solution is far worse than than (admittedly >nasty) problem. And here both library writers have tried to be >careful, at the expense of readability. They left themselves exactly >three characters in which their external names must be distinct. >(They could try numbering them, WM_000, WM_001, etc.) :-) No :-) is needed. Cobol programmers have known this solution for a long time, and the length of distinct characters wasn't even the reason. Names should indeed be numbered: WM_000_long_descriptive_name WM_001_another_long_descriptive_name WM_002_yaldn /* i guess this one wasn't so long :-) */ Yes, renaming is still necessary to deal with several libraries that unfortunately chose the same prefix. Yes the only other solution, licensing, would be worse than the problem. But no one would obey the licensing requirement anyway -- because the licence might prohibit them from defining __STDC__ as 0. -- Norman Diamond, Sony Computer Science Lab (diamond%csl.sony.jp@relay.cs.net) The above opinions are claimed by your machine's init process (pid 1), after being disowned and orphaned. However, if you see this at Waterloo, Stanford, or Anterior, then their administrators must have approved of these opinions.
gwyn@smoke.BRL.MIL (Doug Gwyn) (07/06/89)
In article <3364@buengc.BU.EDU> bph@buengc.bu.edu (Blair P. Houghton) writes: >Which begs the question: how difficult is it to have standard-conforming >implementations implement a linker that handles a larger name space? Many compiler implementors simply do not have the option of changing or replacing the system linker.
jeffrey@algor2.UUCP (Jeffrey Kegler) (07/09/89)
diamond@csl.sony.junet (Norman Diamond) writes: => jeffrey@algor2.uu.net (Jeffrey Kegler) writes: => => [ Discussion of mine of avoiding name conflicts, along with facetious ] => => [ suggestion variables be numbered in the first six characters for ] => => [ distinctness under ANSI C ] => Names should indeed be numbered: => WM_000_long_descriptive_name => WM_001_another_long_descriptive_name => WM_002_yaldn /* i guess this one wasn't so long :-) */ I don't know about anyone else, but there is no way I would remember variable names like that 10 seconds after I coined them. Also, given a conflict of prefixes (which was a premise of the discussion) use of such names *guarantees* conflicts between the libraries, rather than leaving them merely very likely. Norman has a lot of good things (which I did not quote) to say, and that a competent person like him would advocate a miserable naming system like the above shows the desperation to which the six character limit is going to drive us all. The amount of effort that some projects are going to have to go through to obey the 6 character limit will rewrite many a linker. -- Jeffrey Kegler, President, Algorists, jeffrey@algor2.UU.NET or uunet!algor2!jeffrey 1762 Wainwright DR, Reston VA 22090
davecb@yunexus.UUCP (David Collier-Brown) (07/10/89)
jeffrey@algor2.uu.net (Jeffrey Kegler) writes: | [ Discussion of mine of avoiding name conflicts, along with facetious ] | [ suggestion variables be numbered in the first six characters for ] | [ distinctness under ANSI C ] | Norman has a lot of good things (which I did not quote) to say, and | that a competent person like him would advocate a miserable naming | system like the above shows the desperation to which the six character | limit is going to drive us all. | | The amount of effort that some projects are going to have to go | through to obey the 6 character limit will rewrite many a linker. This discussion comes around about every six months. Ahem: 0) 6 characters is a lower limit of significance. You're allowed to use more. 1) Some few companies won't fix their linkers (And don't run Unix, so I hardly care) 2) The process for fixing a linker with "backwards compatibility" is well-known 3) Almost everyone will have to fix their linkers for Ada, or not be able to get US (and some Canadian/NATO) government contracts. Mail me if you want me to post "how to upgrad a linker" once again (probably to comp.algorithms (;-)). --dave -- David Collier-Brown, | davecb@yunexus, ...!yunexus!davecb or 72 Abitibi Ave., | {toronto area...}lethe!dave Willowdale, Ontario, | Joyce C-B: CANADA. 223-8968 | He's so smart he's dumb.
iiit-sh@cybaswan.UUCP (Steve Hosgood) (07/12/89)
In article <2619@yunexus.UUCP>, davecb@yunexus.UUCP (David Collier-Brown) writes: > jeffrey@algor2.uu.net (Jeffrey Kegler) writes: > | The amount of effort that some projects are going to have to go > | through to obey the 6 character limit will rewrite many a linker. > > This discussion comes around about every six months. Ahem: > > 0) 6 characters is a lower limit of significance. You're allowed to use more. Yeah, but though you may be able to use more, a 'strictly conforming' program can't, otherwise it won't port to sites with 6-character linkers. In other words 6 characters *is* the real limit. > 3) Almost everyone will have to fix their linkers for Ada, or not be > able to get US (and some Canadian/NATO) government contracts. > Can't some use be made of that fact? If Ada becomes important due to the military backing, can't 'C' ride its wake (so to speak) and insist on a linker with sensible namewidth? Surely, most manufacturers (even the most stubborn) will upgrade the linkers if several much-wanted languages require such upgrades? I suppose the *real* trick is to persuade the FORTRAN committee to want a wider namespace from now onwards. Chances are that they're considering this already, otherwise FORTRAN won't be able to interface to Ada reliably, and there *must* be *some* requirement for that? Steve -----------------------------------------------+------------------------------ Steve Hosgood BSc, | Phone (+44) 792 295213 Image Processing and Systems Engineer, | Fax (+44) 792 295532 Institute for Industrial Information Techology,| Telex 48149 Innovation Centre, University of Wales, +------+ JANET: iiit-sh@uk.ac.swan.pyr Swansea SA2 8PP | UUCP: ..!ukc!cybaswan.UUCP!iiit-sh ----------------------------------------+------------------------------------- My views are not necessarily those of my employers!
meissner@tiktok.dg.com (Michael Meissner) (07/13/89)
In article <1989Jul1.234330.28732@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: | In article <461@algor2.UUCP> jeffrey@algor2.UUCP (Jeffrey Kegler) writes: | >Whose linker was this, anyway, that we are going to spend the next two | >decades wrecking our code for? The main two mentioned at the meetings were IBM's mainframe linker(s) which uses 8 characters, 1 case (and the library needs some reserved prefixes), and the Honeywell GCOS linker. VMS' linker was also mentioned because it too is a single case linker (though it allows 31 character names). | Any linker that supports the bare minimum for FORTRAN. There are more | such linkers in the world than you'd think. | | > (Couldn't the ANSI C committee have | >found a linker somewhere that was restricted to 5 characters... | | Can you say "Data General"? I knew you could! :-) Fortunately, as I | understand it, even DG agreed that this was DG's mistake, and nobody | seriously suggested munging the standard to match. Actually, by the time the C standards group was formed, the RDOS linker no longer had such a limit. Heck, it had already been obsoleted 10 years ago, when I started working at Data General. I did mention this linker in passing at one meeting I think. In case people are wondering why 5 characters, if you express the symbol in RAD-50 (radix 50) notation, you can fit 5 characters in 32-bits. In a similar fashion, the CDC 6xxx/7xxx/17x computers limited names to 7 characters, because they could fit 7 6-bit 'bytes' plus an 18-bit address into one 60 bit word. These restrictions were to make the linker run faster, since you could do a word or two comparison, instead of calling a general string comparison function. -- Michael Meissner, Data General. Uucp: ...!mcnc!rti!xyzzy!meissner If compiles were much Internet: meissner@dg-rtp.DG.COM faster, when would we Old Internet: meissner%dg-rtp.DG.COM@relay.cs.net have time for netnews?
henry@utzoo.uucp (Henry Spencer) (07/14/89)
In article <547@cybaswan.UUCP> iiit-sh@cybaswan.UUCP (Steve Hosgood) writes: >Yeah, but though you may be able to use more, a 'strictly conforming' program >can't, otherwise it won't port to sites with 6-character linkers. In other >words 6 characters *is* the real limit. Right. This is a fact of life now; it is not an invention of X3J11. >Can't some use be made of that fact? If Ada becomes important due to the >military backing, can't 'C' ride its wake (so to speak) and insist on a >linker with sensible namewidth?... Ada is being rammed down everyone's throats by DoD. X3J11 does not have that kind of clout, and cannot set that sort of requirement without serious risk that major manufacturers will ignore the standard. -- $10 million equals 18 PM | Henry Spencer at U of Toronto Zoology (Pentagon-Minutes). -Tom Neff | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
leech@Apple.COM (Jonathan Patrick Leech) (07/15/89)
In article <1989Jul14.162834.2721@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >In article <547@cybaswan.UUCP> iiit-sh@cybaswan.UUCP (Steve Hosgood) writes: >>Yeah, but though you may be able to use more, a 'strictly conforming' program >>can't, otherwise it won't port to sites with 6-character linkers. In other >>words 6 characters *is* the real limit. >Right. This is a fact of life now; it is not an invention of X3J11. How about if someone identifies the offending environments. Presumably linkers introduced in the future will not suffer under the 6-character restriction, so people willing to flush the currently offending systems from their porting base could work with a more flexible limit. -- Jon Leech (leech@apple.com) Apple Integrated Systems __@/
friedl@vsi.COM (Stephen J. Friedl) (07/16/89)
In article <547@cybaswan.UUCP>, iiit-sh@cybaswan.UUCP (Steve Hosgood) writes: > > Yeah, but though you may be able to use more, a 'strictly conforming' program > can't, otherwise it won't port to sites with 6-character linkers. In other > words 6 characters *is* the real limit. This kind of thing comes up a lot, and it brings up a question I've had in my mind: how many real programs will *really* be strictly conforming? Almost all real programs will have to use libraries (say, Xwin or curses or networking or Informix) that will make the program not strictly conforming. Second, there is a limit to how far we will go in the name of portability, and in many environments there is a good benefit in not being saddled with a six-character limit. Yes, these programs are not portable, but it is straightforward enough to make up a file with #defines that map longnames to shortnames. How many people have the six-char limit foremost in their minds? How about those who never have to deal with these machines? Steve P.S. - Besides, my customer's programmers would laugh at me if I insisted that they worried about the 6-char limit. They think I'm academic enough as it is :-(. -- Stephen J. Friedl / V-Systems, Inc. / Santa Ana, CA / +1 714 545 6442 3B2-kind-of-guy / friedl@vsi.com / {attmail, uunet, etc}!vsi!friedl ---> vsi!bang!friedl <-- NEW "Hard work is a vastly overrated virtue" - my brother
gwyn@smoke.BRL.MIL (Doug Gwyn) (07/16/89)
In article <1150@vsi.COM> friedl@vsi.COM (Stephen J. Friedl) writes: >This kind of thing comes up a lot, and it brings up a question I've >had in my mind: how many real programs will *really* be strictly >conforming? Almost all real programs will have to use libraries >(say, Xwin or curses or networking or Informix) that will make the >program not strictly conforming. Lots of my applications are strictly conforming (e.g. see the information statistics code I recently posted to comp.sources.misc). In other applications, the bulk of the code is strictly conforming with system dependencies isolated in separate modules. In any case, the more portable the bulk of your code is, the less work you have to do when porting. >How many people have the six-char limit foremost in their minds? >How about those who never have to deal with these machines? Since "lint -p" warns about violations of this constraint, it is easy to comply with it. Essentially all my code does -- and I don't have any 6-character monocase linkers to contend with right now. The reason I nevertheless strive for maximum portability is because I never know what environments my code will have to run under in the future, so I make sure that I don't have a lot of work to do to port the code later. This policy has paid off handsomely in the past and I'll stick to it.
scs@itivax.iti.org (Steve C. Simmons) (07/16/89)
friedl@vsi.COM (Stephen J. Friedl) writes: >P.S. - Besides, my customer's programmers would laugh at me if I > insisted that they worried about the 6-char limit. They think > I'm academic enough as it is :-(. Remember the good old days, when using long names meant you was academic? -- Steve Simmons scs@vax3.iti.org Industrial Technology Institute Ann Arbor, MI. "Velveeta -- the Spam of Cheeses!" -- Uncle Bonsai
jfh@rpp386.Dallas.TX.US (John F. Haugh II) (07/18/89)
In article <7734@xyzzy.UUCP> meissner@tiktok.UUCP (Michael Meissner) writes: >In case people are wondering why 5 characters, if you express the >symbol in RAD-50 (radix 50) notation, you can fit 5 characters in >32-bits. RAD-50 gives you three characters per short, or six per long. Also, 36-bit machines still abound with 6 6-bit characters per word. -- John F. Haugh II +-Quote of the month club: ------------ VoiceNet: (512) 832-8832 Data: -8835 | "Computer security is to information InterNet: jfh@rpp386.cactus.org | control as a chastity belt is to UucpNet : <backbone>!bigtex!rpp386!jfh +- birth control" -- Doug Steves --