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 Purtill 
Newsgroups: 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