davel@hpda.UUCP (Dave Lennert) (11/09/85)
We're considering changing our C compiler to *not* prepend an underscore
at the beginning of all external names (functions, variables). Will this
break things? Are there reasons (technical/religious) that we should not
do this? Please respond via MAIL; our news connection is frequently
flakey. I will summarize to the net.
I recall seeing a discussion of this topic before. If someone has an
archive of it, please *mail* it to me.
Thanks!
Dave Lennert {ucbvax, hplabs}!hpda!davel [UUCP]
Hewlett-Packard - 47UX ihnp4!hpfcla!hpda!davel [UUCP]
19447 Pruneridge Ave. hpda!davel@ucb-vax.ARPA [ARPA]
Cupertino, CA 95014 (408) 447-6325 [AT&T]thomas@kuling.UUCP (Thomas H{meenaho) (11/21/85)
In article <1232@hpda.UUCP> davel@hpda.UUCP (Dave Lennert) writes: >We're considering changing our C compiler to *not* prepend an underscore >at the beginning of all external names (functions, variables). Will this >break things? Are there reasons (technical/religious) that we should not >do this? I say don't do it! In one particular C compiler I've seen one can produce perefectly good C code that doesn't work when compiled! Consider the following small example from a 68K machine running V7: main(){ extern long a7; /* perfectly legal declaration */ a7 = 0x1234; } As the variable a7 is declared as external the compiler doesn't allocate any space for it but assumes it will be defined at link time. If I compile this into assembler the resulting code looks something like this: main: link a6,#0 move.l #0x1234,a7 unlk a6 rts As a7 is the stackpointer on a 68K the result will be at best unpredictable with another program! Needless to say the behaviour is the same for any legal register name. -- Thomas Hameenaho, Dept. of Computer Science, Uppsala University, Sweden Phone: +46 18 138650 UUCP: thomas@kuling.UUCP (...!{seismo,mcvax}!enea!kuling!thomas)
guy@sun.uucp (Guy Harris) (11/28/85)
> >We're considering changing our C compiler to *not* prepend an underscore > >at the beginning of all external names (functions, variables). > > I say don't do it! > > (Example where a variable is given the same name as the name used by a > register in the assembler, and all h*ll breaks loose when the code is > assembled, linked, and run) This was (according to DMR) the reason this was done in the first place. I believe the 3Bs assemblers do not pre-define names like "r0" for the registers (I think you say something like "%0"), so they can get away with it. Just make sure that, if you don't prepend an underscore, your assembler has a symbol table completely devoid of built-in symbols when it's started up (i.e., don't put opcodes, registers, etc. into the symbol table). If you do this, the only think you're likely to break is programs that use "nlist" to get symbol names from the kernel or something like that - S5 programs which use "nlist" have "#if u3b"-type stuff around the declaration of the namelist. Guy Harris
thomas@kuling.UUCP (Thomas H{meenaho) (12/05/85)
In article <3040@sun.uucp> guy@sun.uucp (Guy Harris) writes: >> >We're considering changing our C compiler to *not* prepend an underscore >> >at the beginning of all external names (functions, variables). >> >> I say don't do it! >> >This was (according to DMR) the reason this was done in the first place. I >believe the 3Bs assemblers do not pre-define names like "r0" for the >registers (I think you say something like "%0"), so they can get away with >it. I don't like this method of separating register names from identifiers. In the SysV port for the 68K from Motorola they do just that. The net result is that while you might save a few _:s, you loose much readability of the assembler code. The silly %:s makes the code almost unreadable. For C programs it doesn't really matter but when you're forced to do something in assembler it's a pain. I can't see the point why anyone would rather use the verrry frequent %:s in favor of the rare _:s. -- Thomas Hameenaho, Dept. of Computer Science, Uppsala University, Sweden Phone: +46 18 138650 UUCP: thomas@kuling.UUCP (...!{seismo,mcvax}!enea!kuling!thomas)