Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!ihnp4!zehntel!hplabs!hao!seismo!brl-tgr!tgr!Purtill@MIT-MULTICS.ARPA From: Mark PurtillNewsgroups: net.lang.c Subject: Re: External names in other languages Message-ID: <7376@brl-tgr.ARPA> Date: Tue, 15-Jan-85 18:51:34 EST Article-I.D.: brl-tgr.7376 Posted: Tue Jan 15 18:51:34 1985 Date-Received: Mon, 21-Jan-85 03:38:20 EST Sender: news@brl-tgr.ARPA Organization: Ballistic Research Lab Lines: 30 Paul Schauble suggests: > I would like to make a proposal for the new standard. As a basic part of > the standard, allow the construction > > identifier ENTRY "external_name" > > in every context where identifier is visible beyond the current > compilation unit. For example, > > extern int current_date entry "SYS$DATE"; to which shades@mit-oz replies > it is a sound idea admittedly but it seems to me that all you > are doing is the standard(?) practice of > > #define this_is_a_very_long_name xyzzy > int this_is_a_very_long_name; > > when the compiler generates the internal global symbols table then for > the linker all references would be to variable xyzzy. This only works where the external variable (eg xyxxy) is legal in C. The point is that for instance SYS$DATE /isn't/ legal in (standard) C, due to the '$'. Probably one can find OS's with arbitrarily unpleasent characters in system variables (e.g., DG's AOS/VS prepends '?' to all system calls, which could be confused with the ?: operator.) Mark