scs@hstbme.mit.edu (Steve Summit) (09/24/89)
[This is a week-old thread from comp.unix.wizards which has been adequately answered there, but it may be of interest to comp.lang.c readers, particularly any who may still believe that namespace pollution is merely a theoretical problem.] In article <71@promark.UUCP> mark@promark.UUCP (Mark J. DeFilippis) writes: >The following short section of code does not compile using SCO XENIX 2.3.1 >and the 2.2.1 Development system, and I can't figure out why. > >1 main() >2 { >3 char *cdecl; >4 } > >Yields the errors: > error(3) : error 59 : syntax error : ';' > >If you change the name 'cdecl' to anything else, it compiles fine. >(ccdecl, cdecll, work fine, so the only thing I can think of is some >type of a conflict. But a conflict with what??? Their are no macros, >no external functions, no libraries, and the error it reports is a _syntax_ >error of all things, not a linkage error. > >Problems like this we don't need! Who thinks of changing variable names? >I mean, when you hit the point in your debugging that you are trying >to change the name of a variable as a hack, (Like the name should really >make a difference), it's a pretty desperate situation. The problem, of course, is that in many PeeCee environments "cdecl" is a new _keyword_, and keyword namespace pollution is even more onerous than, say, external linkage namespace pollution. Mark's comments perfectly express the exasperation which is (properly) felt by anyone faced with a misguidedly "extended" and therefore nonstandard environment. (No fair saying "but who would ever name a variable 'cdecl?'." The same problem bit me, when I wrote a version of the ever-popular cdecl program.) It should be noted that the PC compiler vendors are belatedly seeing the errors of their ways, and are introducing compiler switches to control the recognition of extended keywords, although the default (which should be that extended keywords are not recognized and are hence available to the programmer) is not always correct.
rhg@cpsolv.UUCP (Richard H. Gumpertz) (09/25/89)
Speaking of switches to disable non-standard extensions: I encountered a funny problem using DEC's VAX/VMS compiler: when I tried to compile with extensions disabled it complained about the extensions that were used in implementing the standard .h files! Interesting dilemma: the (hidden from the programmer) implementation of certain ANSI-standard macros must include DEC-specific extensions. Hence, programs that use the standard headers and functions cannot be compiled with the standard-only switch! I suppose a pragma that would temporarily allow extensions could be included in appropriate parts of the header files. Moby sigh. Richard H. Gumpertz -- ========================================================================== | Richard H. Gumpertz: ...uunet!amgraf!cpsolv!rhg | | Computer Problem Solving, 8905 Mohwak Lane, Leawood, Kansas 66206-1749 | ==========================================================================
russ@bbx.UUCP (Russ Kepler) (09/26/89)
In article <14561@bloom-beacon.MIT.EDU> scs@adam.pika.mit.edu (Steve Summit) writes: >In article <71@promark.UUCP> mark@promark.UUCP (Mark J. DeFilippis) writes: >>The following short section of code does not compile using SCO XENIX 2.3.1 >>and the 2.2.1 Development system, and I can't figure out why. >> >>1 main() >>2 { >>3 char *cdecl; >>4 } >> >>Yields the errors: >> error(3) : error 59 : syntax error : ';' >> >>[ rest deleted for brevity, turn out cdecl is a *keyword*] > >The problem, of course, is that in many PeeCee environments >"cdecl" is a new _keyword_, and keyword namespace pollution is >even more onerous than, say, external linkage namespace >pollution. > >Mark's comments perfectly express the exasperation which is >(properly) felt by anyone faced with a misguidedly "extended" >and therefore nonstandard environment. (No fair saying "but who >would ever name a variable 'cdecl?'." The same problem bit me, >when I wrote a version of the ever-popular cdecl program.) > But this isn't the worst; I couldn't port to a major European hardware platform because they decided that 'near' and 'far' weren't only keywords but that keywords that weren't yet implemented couldn't be redefined... can you say catch-22? After changing only 2500 lines of code (lets see now, sed(1), uh-huh, '-f', yep, 'for i in *.[ch]', there we go) the code will now compile. Then the *real* trouble starts. Lots of code in lots of libraries don't hide the entry points. 'movblk' seems rather more popular than it used to be, 'send' is great when you start including the socket libs (and using 'em). When I'm faced with one of the 'it's got to work!' situations I start looking for common named routines/variables in my code *and* the libs that are being included. A quick 'nm *.a | grep -v ...' to a comm and I can find the duplicate. A quick #define in the highest #include, a recompile and we're back in business... after a few hours of ranting, raving, etc. I wish that somewhere in /lib there was a file of all entry points in all of the libs - and a standard way of comparing with your code's entry points. Any pointers out there? -- Russ Kepler - Basis International SNAILMAIL: 5901 Jefferson NE, Albuquerque, NM 87109 UUCP: {backboneishsite}!unmvax!bbx!russ PHONE: 505-345-5232
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (09/27/89)
Another thing which was left out of the ANSI standard is some name space reserved to the user. That is, some subset of names which they promise not to snatch away in the next standard. The space is getting pretty thin now, with a lot of common user names being used in libraries and stuff, and some user space would be a good thing for consideration in the next standard. SCO added another name to their curses library (I believe it was quit) which conflicts with several programs I use. To top it all off the routine is not in SysV or BSD or even SCO documentation, just an internal name which someone forgot to make static. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "The world is filled with fools. They blindly follow their so-called 'reason' in the face of the church and common sense. Any fool can see that the world is flat!" - anon
scott@bbxsda.UUCP (Scott Amspoker) (09/27/89)
In article <534@crdos1.crd.ge.COM> davidsen@crdos1.UUCP (bill davidsen) writes: >Another thing which was left out of the ANSI standard is some name space >reserved to the user. That is, some subset of names which they promise >not to snatch away in the next standard. The space is getting pretty >thin now, with a lot of common user names being used in libraries and >stuff, and some user space would be a good thing for consideration in >the next standard. It's becoming more and more a problem. It has happened to us much more lately (the past year) than ever before. Our well thought out, descriptive symbol names are starting to show up in system libraries and header files. We have no choice but to do a quick search-and-replace to get the port finished. -- Scott Amspoker Basis International, Albuquerque, NM (505) 345-5232
henry@utzoo.uucp (Henry Spencer) (09/28/89)
In article <534@crdos1.crd.ge.COM> davidsen@crdos1.UUCP (bill davidsen) writes: >Another thing which was left out of the ANSI standard is some name space >reserved to the user. That is, some subset of names which they promise >not to snatch away in the next standard... Section 4.1.2.1 lists several classes of identifiers that are reserved, and then flatly states: "No other identifiers are reserved." That is, ALL other identifiers are explicitly promised to be available to the user. Note also 1.7: "A conformation implementation may have extensions (including additional library functions) provided they do not alter the behavior of any strictly conforming program...", with a footnote: "This implies that a conforming implementation reserves no identifiers other than those explicitly reserved in this Standard." The classes of reserved identifiers are admittedly annoyingly large, but the promise to reserve nothing else is of considerable importance. If by "the next standard" you mean a revised C standard, either the revision will be upward-compatible or not. If so, it has to preserve these promises. If not, then asking today's standard to make promises on its behalf is silly. -- "Where is D.D. Harriman now, | Henry Spencer at U of Toronto Zoology when we really *need* him?" | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
tneff@bfmny0.UU.NET (Tom Neff) (09/28/89)
In article <534@crdos1.crd.ge.COM> davidsen@crdos1.UUCP (bill davidsen) writes: >Another thing which was left out of the ANSI standard is some name space >reserved to the user. That is, some subset of names which they promise >not to snatch away in the next standard. I suggest beginning all identifiers with the prefix leprosy_scab_ as it is unlikely that any ANSI committee would dare to approve any new identifiers within this namespace! -- I'm a Leo. Leos don't believe * * * Tom Neff in this astrology stuff. * * * tneff@bfmny0.UU.NET
gwyn@smoke.BRL.MIL (Doug Gwyn) (09/28/89)
In article <534@crdos1.crd.ge.COM> davidsen@crdos1.UUCP (bill davidsen) writes: >Another thing which was left out of the ANSI standard is some name space >reserved to the user. As you state it, it's simply not true. ALL identifiers not specifically flagged as "reserved" (for the implementation) by the Standard are reserved for the (application) program's use. We staked out whole categories of name space such as is*() for use in future C standards. It is of course up to future C standardization committees to decide whether or not to turn "foo" into a keyword. You can expect that they will have to think even harder than X3J11 about compatibility problems caused by glomming onto previously program-available name space. The other problem you mention, of vendor-supplied libraries clashing with application (or other libraries) use of identifiers, is a real one. An approach like Xlib's (where all its identifiers start with a special reserved pattern "X") is viable, absent support for genuine "classes" or "packages". I would however recommend that more than one character be used for the package-specific prefix. We use two (Xx format) for our internal multiple-package projects, but it may take more to deal with a large raft of vendors.
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (09/28/89)
In article <11157@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn) writes: | In article <534@crdos1.crd.ge.COM> davidsen@crdos1.UUCP (bill davidsen) writes: | >Another thing which was left out of the ANSI standard is some name space | >reserved to the user. | | As you state it, it's simply not true. ALL identifiers not specifically | flagged as "reserved" (for the implementation) by the Standard are | reserved for the (application) program's use. We staked out whole | categories of name space such as is*() for use in future C standards. I see this as the diference between "you can use anything we haven't taken" and "we will never take this." What is not in the standard is any statement like "no future standard library calls will have external names which begin with three alphabetic characters and an underscore. In other words, I was not given a set of names which I can call my own and be assurred will not conflict in the future. | The other problem you mention, of vendor-supplied libraries clashing | with application (or other libraries) use of identifiers, is a real one. On my schedule of things to look at next year is a program which will take an object file and rename global symbols. I know this will break the documentation of the vendor library, but I feel the benefits are worth it. Obviously I would have to rename the references, too. Naturally if I write such a thing I will post it. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "The world is filled with fools. They blindly follow their so-called 'reason' in the face of the church and common sense. Any fool can see that the world is flat!" - anon
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (09/28/89)
In article <1989Sep27.170304.2158@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes: | In article <534@crdos1.crd.ge.COM> davidsen@crdos1.UUCP (bill davidsen) writes: | >Another thing which was left out of the ANSI standard is some name space | >reserved to the user. That is, some subset of names which they promise | >not to snatch away in the next standard... | | [ discussion of names which are reserved ] | | The classes of reserved identifiers are admittedly annoyingly large, but | the promise to reserve nothing else is of considerable importance. But they *didn't* promise not to, they said they haven't yet. The feature I mentioned as missing was a statement that not future reserved words will be of the form {choose one}. | | If by "the next standard" you mean a revised C standard, either the | revision will be upward-compatible or not. If so, it has to preserve | these promises. If not, then asking today's standard to make promises | on its behalf is silly. There are no promises for the future, only the present standard. It would have been simple to define a namespace is intended to be used only by applications. My example in another posting was starting with three alpha chars and an underscore. Thus, if I want to be sure I don't have to edit my source, I can use those names exclusively. I assume that future committees will be composed of thoughtful people. I was on X3J11 for two years until my group ran out of T&L money. Now I'm in another group and I hope that I'll be able to join the next committee. If this future committee had any hint as to what names applications use, they would pick others. What I suggest is that this committee could have passed a hint on to the programmers and any future committees about what space could be left to the application. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "The world is filled with fools. They blindly follow their so-called 'reason' in the face of the church and common sense. Any fool can see that the world is flat!" - anon
henry@utzoo.uucp (Henry Spencer) (09/30/89)
In article <599@crdos1.crd.ge.COM> davidsen@crdos1.UUCP (bill davidsen) writes: >| The classes of reserved identifiers are admittedly annoyingly large, but >| the promise to reserve nothing else is of considerable importance. > > But they *didn't* promise not to, they said they haven't yet... No, they said that no other identifiers are reserved. Period. Full stop. No implementation that conforms to this standard can reserve any other identifiers. None. Zero. Not just today, *ever*. How much more of a promise do you want? > There are no promises for the future, only the present standard... I don't understand why you think today's standard could possibly make any sort of promise that would be binding on a future standard which you have already assumed will be incompatible with the current one, i.e. will break promises made in the current one. (If it is compatible, it will keep the current one's promise and not reserve any more names.) -- "Where is D.D. Harriman now, | Henry Spencer at U of Toronto Zoology when we really *need* him?" | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
bobmon@iuvax.cs.indiana.edu (RAMontante) (09/30/89)
tneff@bfmny0.UU.NET (Tom Neff) <14746@bfmny0.UU.NET> : - -I suggest beginning all identifiers with the prefix - - leprosy_scab_ One of Henry Spencer's Ten Commandments specifies a *unique* six-letter prefix. You've broken that commandment. Are you planning to raze the Commandments along with the rest of Ontario?