rkl@ahuta.UUCP (04/09/85)
REFERENCES: <9726@brl-tgr.ARPA> There usually is a difference between what the C compiler accepts as names and what the ASSEMBLER accepts as names. In general I have found that using only 7 character names is safest, ie. guarantees uniqness. Yes, C is supposed to accept variable names with more that 8 chars, but the assembler may not. For example, try two defining two variables names that match for the first 7 chars but differ in the 8th, and compiling it. I have found that the C compiler has no trouble with this but the assembler prepends an underscore and truncates to 8 chars (so now the variable names match), which of course causes 'compile' errors. I should mention that the above pertains to C compilers in general. Personally, I would stick to a maximum of 7 chars for a variable name. I find long names very annoying and subject to typos. Yes this means more cryptic names, but the solution is to put COMMENTS in your C code (mini-flame: most C programs have extremely little in the way of comments). In addition, shorter names will improve portability. R. Kevin Laux Software Vendor Tech Support ATTIS, Lincroft ahuta!rkl
mjs@eagle.UUCP (M.J.Shannon) (04/10/85)
There is another error in the 7300's SGS (Software Generation System), and that is that the C support routines inhabit the same name space that user defined external symbols use. Thus, a user defining a name like `ldiv' for instance, will cause untold confusion when the linker resolves references to the user's name rather than the library's routine. Fortunately, the linker will complain (in many? most? some? cases) that the name is multiply defined. I found out the hard way.... -- Marty Shannon UUCP: ihnp4!eagle!mjs Phone: +1 201 522 6063
rim@lems.UUCP (04/13/85)
From: rim (Roderick McAllery) > .... In general I have found > that using only 7 character names is safest, ie. guarantees uniqness. > > ...Personally, I would stick to a maximum of 7 chars for a variable > name. I find long names very annoying and subject to typos. Yes this means > more cryptic names, but the solution is to put COMMENTS in your C code. Personally I would rather have clarity than trying to decipher someones cute little acronyms if I had to maintain a piece of code. --- This is one user of C compilers that gets very annoyed at the brain damaged attitude of people who write assemblers that only accept 8 character identifiers. It seems that the 7300 is just another machine that has old type software shuffled onto it. Assemblers written for systems with large address spaces that have symbol tables that cannot handle long identifiers exemplify an attitude that dates back to a time before people were interested in software engineering. Not having used the 7300 I have not had the displeasure to use the assembler in question. However on the basis of its inability to handle long identifiers it seems clear that the persons who were/are responsible for that assembler showed a lack of understanding in designing software that is not restrictive to the user. There is no great trick or mystery in accepting arbitarily long identifiers so why the restriction, especially on AT&T's new 'IBM killer'? -- USnail: Roderick McAllery P.O Box 1216 Brown University Providence 02912 Rhode Island usenet: {decvax,vax135,allegra}!brunix!lems!rim
wong@rtech.ARPA (J. Wong) (04/17/85)
> From: rim (Roderick McAllery) > > > .... In general I have found > > that using only 7 character names is safest, ie. guarantees uniqness. > > > > ...Personally, I would stick to a maximum of 7 chars for a variable > > name. I find long names very annoying and subject to typos. Yes this means > > more cryptic names, but the solution is to put COMMENTS in your C code. > > Personally I would rather have clarity than trying to decipher someones cute > little acronyms if I had to maintain a piece of code. > --- Actually, most C compilers accept identifiers of any length. So you are not limited in having non-cryptic names. However, some assemblers and linkers make the restriction to only recognizing the first n characters. Thus, only the first n characters need be unique, the actual name can be longer. -- J. Wong ucbvax!mtxinu!rtech!wong **************************************************************** You start a conversation, you can't even finish it. You're talking alot, but you're not saying anything. When I have nothing to say, my lips are sealed. Say something once, why say it again. - David Byrne
mgh@hou5h.UUCP (Marcus Hand) (04/17/85)
Oh dear, back to this old question again. If you want your software to run on version 7, Xenix 3, System III etc, etc, as well as SysVr2 and 4.2 BSD, one has to, unfortunately, restrict oneself to making variables unique in the first 7 characters. (ie one fewer on Vaxen than 3Ben). Of course, its much nicer not to have to bother with these niceties (and generally results in more readable code) but we're stuck with an awful lot of sites who either choose not to or cannot afford to run the more recent versions with their fancy assembler/compilers. Life's hard, you know. -- Marcus Hand (hou5h!mgh)
edler@cmcl2.UUCP (Jan Edler) (04/17/85)
We have the System V/68000 tape from AT&T, and it contains a set of tools (C compiler, etc.) that we intend to use but haven't yet. On examination, they seem not to have either of the problems that have been attributed to the 7300 C compiler, namely short external identifiers or name clashes with runtime support routines like ldiv. The System V/68000 C compiler is based on pcc2, and is a more modern compiler than the old one we've been using (based on the MIT pcc-based C compiler). For example, it supports "void *", and no longer supports the old-style assignment operators or initializations (our version of the MIT compiler doesn't even support void). Furthermore, we are expecting a big improvement in the correctness and quality of generated code. Before we fixed it, the MIT compiler also suffered from the name clash problem. Not only was this a problem with routines like lmul or ldiv, but you had to watch out for global variables with names like "sp", "pc", "d0", and so forth. The SV/68 compiler has a nice way of dealing with this; '_' is not prepended to externals, but internal identifiers that should be hidden have a '%' in their names, making clashes with C identifiers impossible. The register names recognized by the assembler have '%'s in them. Jan Edler New York University edler@nyu cmcl2!edler
dan@digi-g.UUCP (Dan Messinger) (04/17/85)
In article <173@lems.UUCP> rim@lems.UUCP writes: >From: rim (Roderick McAllery) > >This is one user of C compilers that gets very annoyed at the brain damaged >attitude of people who write assemblers that only accept 8 character >identifiers. > >It seems that the 7300 is just another machine that has old type software >shuffled onto it. Assemblers written for systems with large address spaces >that have symbol tables that cannot handle long identifiers exemplify >an attitude that dates back to a time before people were interested >in software engineering. I have before me the PC 7300 assembly manual, which says "There is no limit on the length of an identifier", while the C manual says "Although there is no limit on the length of a name, only initial characters are significant: at least eight of a non-external name, and perhaps fewer for external names" My 7300 is not accessible to me at the moment, so I can not try an imperical test, but I would interpret this to mean that the 8 character limit is not a result of the assembler, which is not limited to 8 characters of significance, but a restriction imposed by the C compiler itself. Dan Messsinger ihnp4!umn-cs!digi-g!dan
mash@mips.UUCP (John Mashey) (04/19/85)
I've noticed that there has been a fair amount of philosophical speculation on the topic of why the 7300 doesn't use variable names. The real truth is that it has absolutely NOTHING to do with philosophical issues, but with timing of releases and schedule issues. The sequence is as follows: 1) Convergent's Data Systems Division had been using a tuned-up version of the MIT cc and assmbler. The A-Team (7300 division) started work with this. For various reasons, all compiler/assembler support was kept in DSD, and thus was often tied to DSD release schedules. 2) Last year, we got the 68K SGS (using pcc2) when it became available; we converted to pcc2 fairly quickly, but there was enough other work to do (converting assembler code, reimplementing some optimization in pcc2 that we'd done before for pcc1 and adding more, etc) that we didn't turn on flexnames soon enough for it to get into the 7300 without disrupting release schedules. 3) I certainly can't speak for the A-Team, but I'd be surprised if they didn't use flexnames as they become available.
fnf@unisoft.UUCP (Fred Fish) (04/22/85)
> "d0", and so forth. The SV/68 compiler has a nice way of dealing with > this; '_' is not prepended to externals, but internal identifiers > that should be hidden have a '%' in their names, making clashes with > C identifiers impossible. The register names recognized by the assembler > have '%'s in them. Yes, the assembler uses "%a0", sdb prints it as "a0", and sdb expects input from the user to be "a0%" (as in a0%!45 to set a0 to 45). Of course "splimit%!45", to set global variable "splimit%" to 45 gives "Unknown register variable". Nice and consistent! :-) -Fred