Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site idis.UUCP Path: utzoo!watmath!clyde!bonnie!akgua!mcnc!idis!george From: george@idis.UUCP Newsgroups: net.lang.c Subject: Dollars and Sense Message-ID: <319@idis.UUCP> Date: Fri, 28-Dec-84 21:44:54 EST Article-I.D.: idis.319 Posted: Fri Dec 28 21:44:54 1984 Date-Received: Sun, 30-Dec-84 02:03:17 EST Organization: University of Pittsburgh Lines: 44 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