george@idis.UUCP (12/29/84)
References: gitpyr.422 There has been much discussion lately about using dollar signs in identifier names or providing a mechanism in a C program to associate a particular linker or assembler symbol with a particular identifier. It is clear in both C (K&R 1978) and ANSI C (draft 84-131) that a legal C program does not have dollar signs in identifiers. (Section 10.4 of appendix A with the ANSI draft discusses this, but it is explicitly stated that this is not part of the standard.) Since a program which has dollar signs in tokens is distinct from any legal program, a compiler is free to do anything with it including treating those tokens as identifiers. Robert Viduya in article gitpyr.422 says: > Perhaps what C really needs is a way to define a seperate external name for > an identifier when declaring that identifier. For example, the following: > > extern sys_read "SYS$READ" (); > > would tell the compiler/linker to call the entrypoint "SYS$READ" whenever > "sys_read" was called in the source. I do not think that C source is the appropriate place to put this information, but if one must, why not use the normal mechanism. asm("_sys_read = SYS$READ") ; On many UNIX brand systems, subroutines that call system calls are written in assembly language and the object code is put in a library. The subroutines provide both the appropriate subroutine linkage and return sequence for C programs and the appropriate naming convention for C programs. This seems to me to be a reasonable solution that could be used in other applications or systems if it is necessary to deal with strange symbols. This is probably preferable to all of the preceding methods of dealing with such symbols. George Rosenberg idis!george
kpmartin@watmath.UUCP (Kevin Martin) (12/31/84)
>There has been much discussion lately about using dollar signs >in identifier names or providing a mechanism in a C program >to associate a particular linker or assembler symbol with a particular >identifier. >I do not think that C source is the appropriate place to put >this information, but if one must, why not use the normal mechanism. > > asm("_sys_read = SYS$READ") ; Not every C compiler passes through an assembler. Not every C compiler supports the 'asm' "function". Even among C compilers which call assemblers, not all of them call 'as'. >On many UNIX brand systems, subroutines that call system calls >are written in assembly language and the object code is put in a library. >The subroutines provide both the appropriate subroutine linkage and return >sequence for C programs and the appropriate naming convention for C programs. >This seems to me to be a reasonable solution that could be used >in other applications or systems if it is necessary to deal >with strange symbols. > George Rosenberg > idis!george There is more in question than UNIX systems. Some of the strange names exist because of restrictions in the library implementation language (e.g. assembler), such as not allowing leading underscores in external names. Kevin Martin, UofW Software Development Group
tim@cmu-cs-k.ARPA (Tim Maroney) (12/31/84)
Using "asm( whatever )" to change the names of symbols is flawed for the same reasons assembly language output processing is. There are compilers which neither put out assembly language nor have the capability to interpret unusual (or any) "asm" statements. I think the best idea so far was improving linkers so that they can do it. Another option is to write programs for the various systems that filter object files' symbol tables to change the names as desired. This means you don't have to mess with the existing linkers, just insert another post-compilation processing phase. I don't think a prototype program to do this on UN*X would be very hard, but I don't have the time now myself. -=- Tim Maroney, Carnegie-Mellon University Computation Center ARPA: Tim.Maroney@CMU-CS-K uucp: seismo!cmu-cs-k!tim CompuServe: 74176,1360 audio: shout "Hey, Tim!" "Remember all ye that existence is pure joy; that all the sorrows are but as shadows; they pass & are done; but there is that which remains." Liber AL, II:9.
mat@hou4b.UUCP (Mark Terribile) (01/09/85)
>Using "asm( whatever )" to change the names of symbols is flawed for the >same reasons assembly language output processing is. There are compilers >which neither put out assembly language nor have the capability to interpret >unusual (or any) "asm" statements. >I think the best idea so far was improving linkers so that they can do it. >Another option is to write programs for the various systems that filter >object files' symbol tables to change the names as desired. > Tim Maroney, Carnegie-Mellon University Computation Center But Tim, there are some brain-damaged systems that only allow ``privileged'' programs to tinker with object files. The HP3000 is on such system. In order to protect the integrity of the OS, never mind user programs, the segmentation control has to be enforced by the assembler and linker ... and what's worse, the program has a final link needed when the program is loaded to run. THAT linker is built into the OS. Perhaps your real-world CS is as colored as your philosophy :-) (THAT discussion by private mail, please) -- from Mole End Mark Terribile (scrape .. dig ) hou4b!mat ,.. .,, ,,, ..,***_*.