poser@csli.Stanford.EDU (Bill Poser) (10/22/90)
I like to use long descriptive identifier names, even for external functions. The standard does not guarantee that these will all be unique, due to the existence of nasty crufty old linkers that may not distinguish them. On the machines on which I am accustomed to working (HP 9000/300 series, SUN 3 and 4, Microvax, VAX, all under UNIX) I have never encountered a problem. Are there any modern workstations, minis, or micros on which I am likely to encounter a problem, or am I correct in assuming that all of the problematic linkers are on old machines or mainframes that I am very unlikely to care about? Bill Poser
steve@taumet.com (Stephen Clamage) (10/22/90)
poser@csli.Stanford.EDU (Bill Poser) writes:
!I like to use long descriptive identifier names, even for
!external functions. The standard does not guarantee that
!these will all be unique, due to the existence of nasty crufty
!old linkers that may not distinguish them. ...
!... am I correct in assuming that
!all of the problematic linkers are on old machines or mainframes
!that I am very unlikely to care about?
Yes, you are correct -- until your code gets ported to a system which
does not support long external names. Your local Tarot reader will be
able to tell when or whether that will happen.
--
Steve Clamage, TauMetric Corp, steve@taumet.composer@csli.Stanford.EDU (Bill Poser) (10/23/90)
In article <487@taumet.com> steve@taumet.com (Stephen Clamage) writes: > >Yes, you are correct -- until your code gets ported to a system which >does not support long external names. Your local Tarot reader will be >able to tell when or whether that will happen. Nope. I'm talking about code entirely under my control, and which given its nature (it requires graphics facilities, a mouse, lots of memory, etc.) is extremely unlikely to be ported to old machines.
chip@tct.uucp (Chip Salzenberg) (10/24/90)
According to poser@csli.stanford.edu (Bill Poser): >I'm talking about code entirely under my control... Today. >...and which given its nature (it requires graphics facilities, >a mouse, lots of memory, etc.) is extremely unlikely to be ported >to old machines. Yet *some* routines will certainly be useful on old machines. From my wall: "10. Thou shalt foreswear, renounce, and abjure the vile heresy which claimeth that 'All the world's a VAX', and have no commerce with the benighted heathens who cling to this barbarous belief, that the days of thy program may be long even though the days of thy current machine be short." -- "The Ten Commandments for C Programmers" by Henry Spencer -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> "I've been cranky ever since my comp.unix.wizards was removed by that evil Chip Salzenberg." -- John F. Haugh II
jamiller@hpcupt1.cup.hp.com (Jim Miller) (10/24/90)
> >Nope. I'm talking about code entirely under my control, and which >given its nature (it requires graphics facilities, a mouse, lots of memory, >etc.) is extremely unlikely to be ported to old machines. >---------- -- or to a mainframe (as mentioned in your 1st post)? jim miller jamiller@hpmpeb7.cup.hp.com
poser@csli.Stanford.EDU (Bill Poser) (10/24/90)
In article <272477A0.6845@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >According to poser@csli.stanford.edu (Bill Poser): >>I'm talking about code entirely under my control... > >Today. What makes you think that's going to change? >>...and which given its nature (it requires graphics facilities, >>a mouse, lots of memory, etc.) is extremely unlikely to be ported >>to old machines. > >Yet *some* routines will certainly be useful on old machines. If somebody is actually going to pull out those routines, he or she can certainly rename them, right? And the long descriptive names may even help this person to find the routines of interest. >"10. Thou shalt foreswear, renounce, and abjure the vile heresy which > claimeth that 'All the world's a VAX', and have no commerce with > the benighted heathens who cling to this barbarous belief, that > the days of thy program may be long even though the days of thy > current machine be short." True, but irrelevant. The use of long identifiers is much more portable than the sort of thing Henry is talking about here (such as assuming you can put pointers into ints, the canonical heresy), can be expected to become more portable (as old crufty linkers go away) and is trivally modifiable when you encounter a machine on which it doesn't work. There are even programs available to do this.
hp@vmars.tuwien.ac.at (Peter Holzer) (10/25/90)
chip@tct.uucp (Chip Salzenberg) writes: >From my wall: >"10. Thou shalt foreswear, renounce, and abjure the vile heresy which > claimeth that 'All the world's a VAX', and have no commerce with > the benighted heathens who cling to this barbarous belief, that > the days of thy program may be long even though the days of thy > current machine be short." > -- "The Ten Commandments for C Programmers" by Henry Spencer And a few lines higher on your wall (and mine) it reads: 9. Thy external identifiers shall be unique in the first six characters, though this harsh discipline be irksome and the years of its necessity stretch before thee seemingly without end, lest thou tear thy hair out and go mad on that fateful day when thou desirest to make thy program run on an old system. But replacing long identfiers by short ones can be automated easily with an awk script or the shroud program posted a few months ago, so I don't think the length of identifiers should be a criterion while writing your program. IMHO you should write your program readable, and long identifiers add a lot to readability. Restricting identifier names to 6 characters is a BUG and not a FEATURE, and I think you should work around bugs only if you encounter them. There are other problems with porting C programs that are a lot more difficult to solve (especially between ANSI-C and pcc-derivatives), so lets concentrate on solving these. -- | _ | Peter J. Holzer | Think of it | | |_|_) | Technical University Vienna | as evolution | | | | | Dept. for Real-Time Systems | in action! | | __/ | hp@vmars.tuwien.ac.at | Tony Rand |
scs@adam.mit.edu (Steve Summit) (10/26/90)
In article <1925@tuvie> hp@vmars.tuwien.ac.at (Peter Holzer) writes: >IMHO you should write your program readable, and long identifiers add a lot >to readability. Restricting identifier names to 6 characters is a BUG... You can have your cake and eat it too. You don't have to limit external identifiers to six characters, you just have to keep them unique in the first six characters. You can have a routine called poweron() as long as you don't also have one called poweroff(). From time to time I come across "maximally portable" subroutine libraries which have slavishly kept all of their 2,574 external identifiers to exactly six characters, and they might as well have been run through a shrouding program. (Or were they C ports of some old Fortran libraries, and did some old version of Fortran limit identifiers to no more than six characters?) Steve Summit scs@adam.mit.edu
bruce@seismo.gps.caltech.edu (Bruce Worden) (10/26/90)
hp@vmars.tuwien.ac.at (Peter Holzer) writes: > [ .... ] [ from Henry Spencer's Ten Commandments... ] >9. Thy external identifiers shall be unique in the first six > characters, though this harsh discipline be irksome and the > years of its necessity stretch before thee seemingly without > end, lest thou tear thy hair out and go mad on that fateful > day when thou desirest to make thy program run on an old system. > >IMHO you should write your program readable, and long identifiers add a lot >to readability. Restricting identifier names to 6 characters is a BUG and >not a FEATURE, and I think you should work around bugs only if you encounter >them. I don't think Mr. Spencer is trying to tell you to restrict your identifiers to six characters, but to make them unique in the first six characters. (I think that because that is exactly what he wrote.) So: int this_here_function(); is okay as long as you don't have int this_here_other_function(); in the same program. -------------------------------------------------------------------------- C. Bruce Worden bruce@seismo.gps.caltech.edu 252-21 Seismological Laboratory, Caltech, Pasadena, CA 91125
peter@ficc.ferranti.com (Peter da Silva) (10/26/90)
> >...and which given its nature (it requires graphics facilities, > >a mouse, lots of memory, etc.) is extremely unlikely to be ported > >to old machines. IBM PS/2 Model 30 running Windows 286? Sizeof(char *) == 4, sizeof(int) == 2. Come again? -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
poser@csli.Stanford.EDU (Bill Poser) (10/26/90)
I know of a guy who used a coding scheme for the names of his Fortran subroutines. He encoded things like the number of parameters and the type of the result, e.g. i6b23 for a routine that returned an int and took six parameters etc. Very helpful in figuring out what the subroutine does.
poser@csli.Stanford.EDU (Bill Poser) (10/26/90)
In article <I3O6UI7@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >> >...and which given its nature (it requires graphics facilities, >> >a mouse, lots of memory, etc.) is extremely unlikely to be ported >> >to old machines. > >IBM PS/2 Model 30 running Windows 286? Sizeof(char *) == 4, sizeof(int) == 2. > >Come again? I think that Peter has misread the message of mine that he quotes. I said that assuming that one could store a pointer in an int was the sort of machine dependency that SHOULD be assiduously avoided.
datanguay@watmath.waterloo.edu (David Adrien Tanguay) (10/26/90)
In article <1990Oct25.182246.27505@nntp-server.caltech.edu> bruce@seismo.gps.caltech.edu (Bruce Worden) writes: >hp@vmars.tuwien.ac.at (Peter Holzer) writes: >> [ .... ] [ from Henry Spencer's Ten Commandments... ] >>9. Thy external identifiers shall be unique in the first six >> characters, though this harsh discipline be irksome and the >> years of its necessity stretch before thee seemingly without >> end, lest thou tear thy hair out and go mad on that fateful >> day when thou desirest to make thy program run on an old system. >> >>IMHO you should write your program readable, and long identifiers add a lot >>to readability. > >I don't think Mr. Spencer is trying to tell you to restrict your identifiers >to six characters, but to make them unique in the first six characters. My primary development environment is a Honeywell running GCOS, with the 6 character caseless restriction in effect. Despite this, I would rather see programs with suitable identifiers. It's fairly easy to fix any problems with long identifiers. The big problems in porting software to this system are byte size assumptions, pointer format assumptions, and "all the world's a Unix" library assumptions. A port usually involves lots of rewriting, and the extra readability of longer identifiers makes it easier to do this rewriting. -- David Tanguay Software Development Group, University of Waterloo
henry@zoo.toronto.edu (Henry Spencer) (10/26/90)
In article <1925@tuvie> hp@vmars.tuwien.ac.at (Peter Holzer) writes: >"9. Thy external identifiers shall be unique in the first six > characters, though this harsh discipline be irksome..." > ... >...Restricting identifier names to 6 characters is a BUG ... Quite. Which is why the Commandment doesn't call for that. Read it again. -- The type syntax for C is essentially | Henry Spencer at U of Toronto Zoology unparsable. --Rob Pike | henry@zoo.toronto.edu utzoo!henry
buck@granite.cr.bull.com (Kenneth J. Buck) (10/26/90)
others have written: >>> [ .... ] [ from Henry Spencer's Ten Commandments... ] >>>9. Thy external identifiers shall be unique in the first six >>> characters, though this harsh discipline be irksome and the >>> years of its necessity stretch before thee seemingly without >>> end, lest thou tear thy hair out and go mad on that fateful >>> day when thou desirest to make thy program run on an old system. This need not be a problem, IF your COMPILER supports long symbol names (we're not talking about the linker here...). Your code can have lots of functions like: int long_function_name1 (stuff) ; int long_function_name2 (stuff) ; int long_function_name3 (stuff) ; . . . and if you have a requirement that the external names be short, then include a header file which redefines all the long names into short names, like: #define long_function_name1 aaaaa0 #define long_function_name2 aaaaa1 #define long_function_name3 aaaaa2 . . . This won't work if your compiler only supports short identifiers, but it will be fine for the case whether the only restriction is the length of the external names. That way, you can write code with long function names, and it can still be portable if necessary, by just remaping the names in the header file. Note: Some compilers use a name-mapping algorithm in order to achieve the external symbol name-length restrictions, instead of just truncating the name (something like, eliminate vowels starting from right to left, then consonants, etc., until no more than 6 chars remain, or whatever...).
n025fc@tamuts.tamu.edu (Kevin Weller) (10/26/90)
In article <1990Oct26.115021.6330@watmath.waterloo.edu> datanguay@watmath.waterloo.edu (David Adrien Tanguay) writes: > ..... The big problems in porting software to > this system are byte size assumptions, pointer format assumptions, and > "all the world's a Unix" library assumptions. ..... ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Agreed on all points but the last one. Though I will try to avoid specific Unix implementation dependencies, I will always BLATANTLY assume a Unix environment of some kind. Sorry, can't help myself! :-) > -- > David Tanguay Software Development Group, University of Waterloo -- Kev PS: I hope I didn't misunderstand your meaning here.
harish@ecelet.ncsu.edu (Harish Hiriyannaiah) (10/27/90)
In article <1990Oct25.182246.27505@nntp-server.caltech.edu> bruce@seismo.gps.caltech.edu (Bruce Worden) writes: >hp@vmars.tuwien.ac.at (Peter Holzer) writes: >> [ .... ] [ from Henry Spencer's Ten Commandments... ] > >I don't think Mr. Spencer is trying to tell you to restrict your identifiers >to six characters, but to make them unique in the first six characters. (I >think that because that is exactly what he wrote.) So: > > int this_here_function(); > >is okay as long as you don't have > > int this_here_other_function(); > >in the same program. This is certainly one of my pet peeves. In the interests of readability, the programmer is required to adhere to a strict naming convention, and at the same time, adhere to uniqueness in the first six characters. This , IMHO is unduly restrictive. Given a choice between portability and code maintainability (is there such a word? :-) ) I would throw the six-character-uniqueness out of the window. I would say, throw such restrictive linkers and compilers down the chute. The current mess in naming conventions (or lack of convention) in the standard C library is a case in point. I can attribute 25% of my programming headaches to such poorly defined name spaces. ( Let's start a new group. comp.trash.the.restrictive.linkers :-) :-) ) harish pu. hi. harish@mrips.bgsm.wfu.edu
n025fc@tamuts.tamu.edu (Kevin Weller) (10/30/90)
In a mail response, jrbd@craycos.com (James Davies) writes: > I'm afraid you did misunderstand. The "this system" mentioned in the > original quote was NOT a Unix system, but a CP-6 system. If you reflect > on your response, you might begin to understand why these library > assumptions are a problem (i.e. lots of people think the way you > expressed it, assuming that all the world IS a Unix system. Sorry, > but it isn't.) > Jim Davies > jrbd@craycos.com > > p.s. In fact, it would probably be closer to the truth to say > "most of the world's an MS-DOS system". Sad, but true. Whoops! Looks like my post was too concise, i.e., open for interpretation. I did not mean to imply that "all the world IS a UNIX," only that my programs assume UNIX for any system on which they run. This obviously means that they simply won't run on a great many existing machines, certainly a problem for those wishing to run them on non-UNIX systems. As regards MS-DOS, you're right again, although I might point out that UNIX makes for a more "portable" environment in the qualitative sense (it runs on many different processors in systems of many different sizes and configurations). -- Kev
n025fc@tamuts.tamu.edu (Kevin Weller) (10/30/90)
In a mail response, datanguay@watmath.waterloo.edu (David Adrien Tanguay) writes: > > So you are claiming that Unix library assumptions are *not* a problem when > porting software to GCOS? I didn't think so :-) > > None the less, if you assume a Unix environment, then your software is not > portable. If you don't care, fine. It is generally fairly simple, however, > to isolate non-portable functionality into clearly marked system dependent > modules, which helps anybody who might someday attempt to port your software > to some non-Unix (non-Posix) system. > -- > David Tanguay Software Development Group, University of Waterloo That's not what I meant to say (my incomplete statements have struck again! :-). Like I told Mr. Davies, my programs assume they're running under UNIX, NOT that every machine runs UNIX (quite false). There are simply too many "standards" out there to support, so I choose a reasonable (IMHO) subset of them which covers many different hardware platforms (something no other operating system has done so successfully as UNIX). There are no absolute portability standards, as I'm sure you're well aware. Even if I choose to explicitly support UNIX in general, I undertake no small task, a direct consequence of the multiplicity of Unices out there. I realize now that I have indeed hidden many of the system dependencies in library functions simply as a result of modular programming practices, so we might say that I implicitly support other operating systems provided they have the same basic functionality as UNIX (it would be kind of hard to find the equivalent multitasking, multiuser, record-locking, etc., features under something as primitive as MS-DOS, for instance). I'm not familiar with GCOS (heck, I'd never even heard of it until your original post), but if it has these *essential* capabilities, then it should be easy to port, say, my C ISAM library there. I was in a situation similar to yours for several years when I was working under OS-9, Microware's multitasking, multiuser operating system for Motorola series CPU's, so I guess I can't really make myself insensitive in good conscience. -- Kev
jamiller@hpcupt1.cup.hp.com (Jim Miller) (10/31/90)
> As regards MS-DOS, you're right again, although >I might point out that UNIX makes for a more "portable" environment in >the qualitative sense (it runs on many different processors in systems >of many different sizes and configurations). > >-- Kev >---------- Ah, "qualitative"? Do you want it to run on the most MACHINES? MS-DOS Do you want it to run on the most SELLER'S machines? MS-DOS Do you want it to run on the most MANUFACTURER'S machines? MS-DOS Do you want it to run on the most different CPU (chip/CPU only, not including differences in mother boards)? UNIX Do you want it to run on the most wide range of mips? UNIX(?) Do you want it to run on a standard OS that all sellers agree on the implementation? MS-DOS (sorry I couldn't resist that last poke). I'm claiming you have picked a meaning of "qualitative" that is self serving. *I* never pick my definitions that way :-) jim - ok. ok. so it's a drift - miller jamiller@hpmpeb7.cup.hp.com (a.k.a James A. Miller; Jim the JAM; stupid; @!?$$!; ... ) Anything I say will be used against me ... But my company doesn't know or approve or condone anything of mine here.
news@macuni.mqcc.mq.oz (USENET News System) (10/31/90)
poser@csli.stanford.edu (Bill Poser): > ... wants to know about long external identifier names ... In article <272477A0.6845@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: > ... quotes Spencer's 10th [9th?] commandment for C programmers I wonder about this. Why not have your long variable names, and for your crummy 6-chars-only machine #include a file with stuff like: #define LN1 long_name_one #define LN2 long_name_two ... ------------------- James Picton-Warlow, jamespw@mqcomp.mqcs.mq.oz.au or some such
n025fc@tamuts.tamu.edu (Kevin Weller) (11/01/90)
NOTE THE FOLLOWUP-TO FIELD ABOVE. This discussion is evolving outside the scope of comp.lang.c, so we should probably shift over to alt.religion.computers exclusively. I originally wrote: > .... > As regards MS-DOS, you're right again, although >I might point out that UNIX makes for a more "portable" environment in >the qualitative sense (it runs on many different processors in systems >of many different sizes and configurations). > .... In article <5940045@hpcupt1.cup.hp.com> jamiller@hpcupt1.cup.hp.com (Jim Miller) writes: > Ah, "qualitative"? > Do you want it to run on the most MACHINES? MS-DOS > Do you want it to run on the most SELLER'S machines? MS-DOS > Do you want it to run on the most MANUFACTURER'S machines? MS-DOS > Do you want it to run on the most different CPU (chip/CPU only, not > including differences in mother boards)? UNIX > Do you want it to run on the most wide range of mips? UNIX(?) > Do you want it to run on a standard OS that all sellers agree on > the implementation? MS-DOS > > (sorry I couldn't resist that last poke). > > I'm claiming you have picked a meaning of "qualitative" that is > self serving. *I* never pick my definitions that way :-) > > > jim - ok. ok. so it's a drift - miller Look up qualitative in the dictionary. A qualitative difference is one of KIND (as in hardware in this case); a quantitative difference is one of NUMBER (as in number of systems running MS-DOS as opposed to UNIX). I hardly see this usage as self-serving. MS-DOS clearly wins in number of computers running it. It's a sad fact, but I don't deny it. I hope against hope that this situation will evenutally change. You must realize that popularity alone doesn't make a good operating system, although it certainly plays a role. MS-DOS is such a backwards OS because it lacks some of the most important and productive functions of operating systems, namely decent multi-tasking, multi-user support and a truly unified I/O scheme. Sure, one can go out and buy packages to provide some of this functionality under DOS, but then one has lost the value of DOS standards, or reliability, or both. I regularly go between various UNIX implementations with no difficulty. For instance, I can and do run many of the same programs on my 386 that I also run on the campus Amdahl mainframe, simply because both machines do UNIX (this is not the only example I could give from my own personal experience). I can even run DOS programs when I must (such as Turbo Pascal, which we use in class for some reason) just by starting a DOS-as-an-application session, and I can readily switch among DOS and UNIX tasks. I think running DOS as a UNIX task really puts it in its place! :-) I admit that the various UNIX implementations are not perfectly identical, but in general they are compatible enough with one another for all practical purposes. In other words, we don't need an absolute agreement on every aspect of the environment, just most aspects. Again, consider my own inter-UNIX successes. I think I've reached a good compromise between compatibility and a decent OS environment. -- Kev
boyd@necisa.ho.necisa.oz (Boyd Roberts) (11/01/90)
In article <698@macuni.mqcc.mq.oz> news@macuni.mqcc.mq.oz (USENET News System) writes: >I wonder about this. Why not have your long variable names, and for your >crummy 6-chars-only machine #include a file with stuff like: > >#define LN1 long_name_one >#define LN2 long_name_two Eh? Do you understand the operation of the the preprocessor? Boyd Roberts boyd@necisa.ho.necisa.oz.au ``When the going gets wierd, the weird turn pro...''
stanley@phoenix.com (John Stanley) (11/01/90)
jamiller@hpcupt1.cup.hp.com (Jim Miller) writes: > Ah, "qualitative"? > Do you want it to run on the most MACHINES? MS-DOS > <lots of Do you's deleted...> > Do you want it to run on a standard OS that all sellers agree on > the implementation? MS-DOS Do you want it to run on a machine that isn't crippled by a 640k memory limit? UNIX Do you want it to run on a machine that isn't crippled by a segmented architecture? UNIX Do you want it to run on a machine that has a virtual memory limit of gigabytes? UNIX Do you want it to run in a system where you can have real multi-user multi-tasking? UNIX Do you want to run it on systems where the lowest common denomenator is a 4.7MHz, 8 bit, no graphics system? MS-DOS > > (sorry I couldn't resist that last poke). I couldn't either. > > I'm claiming you have picked a meaning of "qualitative" that is > self serving. *I* never pick my definitions that way :-) It just depends on what you consider 'quality'. Some have higher standards than others. "Arinth is a beautiful planet." "Oh, have you been there?" "Yes, but not yet." The Doctor. (TB)
morse@currituck.cs.unc.edu (Bryan Morse) (11/01/90)
Before this turns into a full blown UNIX vs. MS-DOS bash (inappropriate for this newsgroup anyway), let me point out that the original poster used in word "qualitative" in reference to portability, not "quality" in reference to operating systems. By this, I assume he meant portability in terms of types of systems vs. (quantitative) portability in terms of number of systems. In this regards, UNIX is indeed _qualitatively_ a more portable environment than MS-DOS. Not better (well...), not on as many individual machines (yet), but certainly to be found on more _types_ of systems than MS-DOS (by this I mean different architectures--instruction sets, word lengths, etc., not vendors). No one was picking on anyone else's favorite OS, so why don't we return back to a discussion of C? Bryan Morse University of North Carolina at Chapel Hill morse@cs.unc.edu Department of Computer Science
karl@ima.isc.com (Karl Heuer) (11/05/90)
In article <1990Oct26.160212.14926@granite.cr.bull.com> buck@granite.cr.bull.com (Kenneth J. Buck) writes: >Note: Some compilers use a name-mapping algorithm in order to achieve the >external symbol name-length restrictions, instead of just truncating the name >(something like, eliminate vowels starting from right to left, then >consonants, etc., until no more than 6 chars remain, or whatever...). Such compilers are not ANSI-conforming, since ANSI C requires the compiler to distinguish between, say, "getchar" and "getchr". Karl W. Z. Heuer (karl@ima.isc.com or uunet!ima!karl), The Walking Lint
news@macuni.mqcc.mq.oz (USENET News System) (11/10/90)
In article <1907@necisa.ho.necisa.oz> boyd (Boyd Roberts) writes: >In article <698@macuni.mqcc.mq.oz> I (USENET News System) write: >>Why not have your long variable names, and for your >>crummy 6-chars-only machine #include a file with stuff like: >>#define LN1 long_name_one >>#define LN2 long_name_two > >Eh? Do you understand the operation of the the preprocessor? Yes, but I made a mistake. Obviously I should have written #define long_name_one LN1 #define long_name_two LN2 so please suppose that I did. What then of the 9th commandment?