Paul Schauble <Schauble@MIT-MULTICS.ARPA> (01/14/85)
I just received this item on the CP/M mailing list: ---------------------------------------------------------------------- [2202] (58 lines) PLS5.PDO1 01/14/85 0349.4 est Mon Info-CPM Subject: Re: an old idea whose time has come Date: Monday, 14 January 1985 02:32 est From: John C. Klensin <Klensin> To: info-cpm at AMSAA Let me add two things to this discussion, which may or may not be helpful: The *equat feature of the 1130 linker also appeared in an early version of the OS/360 "linkage editor", with the keyword CHANGE (If I recall) and a slightly different syntax. This feature has been carried forward into subsequent versions of the related operating systems, so it was not an idea that appeared and disappeared because almost no one found it interesting. Note, however, that as soon as one generalizes the characters that can appear in some places and not in others, that the linker (or whatever) needs special syntax, like quoting characters, to delimit strings that might otherwise not be acceptable to it [either]. Although sharing some sympathy for the linker plan, I see it more as a useful mechanism for patching things up at the last possible moment than as a good solution. A better solution involves seeing it as just another case of binding the semantics of a name in a program (e.g., something that obeys the C (or whatever) naming rules to that name, where the "external" form, whether longer or of a different case or symbol structure, is just part of the semantics. A near variation of the problem that illustrates the point appears when you think, not of "how to get a $ into a name", but about inter-language procedure calls (or external (global) variable references of other sorts) where two or more statically compiled languages have different rules about the naming of such variables. ANSI X3J1 (PL/I) had a long series of discussions on this one a year or two ago in the context of languages that supported case sensitivity in identifiers and operating systems that did not, languages that didn't and operatings systems that did, and languages that had "everything goes to upper" mapping rules and those that preserved case sensitivity. The conclusion was that, while it was probably a good idea to have some name-changing and mapping linker facilities also (whatever that might mean in a host independent way), it should be possible, for a number of reasons, to make these bindings at compile time also. Unless the committee changes its mind (very unlikely, but I am obligated to say things like that), the next version of the PL/I standard will go out for public comment with an optional extension to the syntax for external names, in the form of EXTERNAL (...) s.t., in a particularly bizzare case, you might write dcl sub1 external("avery_long$name_with_all_sorts#@%^&of NONSENSEinIT"); what goes between the parens is, clearly, an implementation-dependent and otherwise unrestricted character string. It can even be a character variable, as long as its value is known at transation time. It is also pretty easy to implement, even if only by preparing, and passing along, a few instructions to the linker as part of the translator's output. Note also that this type of approach permits either name (or, if the capability is otherwise available, both names) to be made available in the symbol table, since the translator has all the information available when the symbol table is constructed. ---[2202]--- ---------------------------------------------------------------------- In view of the recent discussion here about using the ENTRY keyword to provide an external name, I find this very interesting. 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"; <identifier> is a normal C identifier in all respects, including length. <external_name> is a normal C string constant, including processing escapes such as \n \ \" and so on, whose meaning is implementation defined. Two such declarations with the same external_string will be matched by the loader. This provides the means to reference naames defined in other languages and permits a way around the length of external names problem. If this feature is consistantly used, it will localize all system dependant name requirements to the single declaration. Comments?? Paul Schauble Schauble @ MIT-Multics.ARPA
MLY.G.SHADES%MIT-OZ@MIT-MC.ARPA (01/15/85)
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. nice try but no dice i think shades@mit-oz
Mark Purtill <Purtill@MIT-MULTICS.ARPA> (01/16/85)
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
ndiamond@watdaisy.UUCP (Norman Diamond) (01/21/85)
> 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. > > nice try but no dice i think > > shades@mit-oz The problem originally came about because xyzzy sometimes isn't a valid identifier in C. Putting it in a #define doesn't make it valid. -- Norman Diamond UUCP: {decvax|utzoo|ihnp4|allegra|clyde}!watmath!watdaisy!ndiamond CSNET: ndiamond%watdaisy@waterloo.csnet ARPA: ndiamond%watdaisy%waterloo.csnet@csnet-relay.arpa "Opinions are those of the keyboard, and do not reflect on me or higher-ups."
bsa@ncoast.UUCP (Brandon Allbery (the tame hacker on the North Coast)) (01/24/85)
> Article <7332@brl-tgr.ARPA>, from MLY.G.SHADES%MIT-OZ@MIT-MC.ARPA +---------------- | 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; Which works fine if the name happens to only contain characters legal in C identifiers. IBM 370 labels can contain $, #, and @. The first is allowed in SOME C implementations; the other two are allowed in no C that I know of. You can't #define #define ibm_370_ext_func SYS#FOO$ --bsa -- Brandon Allbery @ decvax!cwruecmp!ncoast!bsa (..ncoast!tdi1!bsa business) 6504 Chestnut Road, Independence, Ohio 44131 +1 216 524 1416 (or what have you) Who said you had to be (a) a poor programmer or (b) a security hazard to be a hacker?