dcbrown@watbun (03/09/83)
I was reading the note in Unix-Wizards about the
renaming problem with system libraries, and while I understood
the assumptions made, from using both B and C, it seems apparent
that other readers didn't.
Firstly, the functions in the library have both a "nor-
mal" name and a "dot" name, so that one can call "scan" in either
B or C and get the function CURRENTLY known as scan. This is the
normal case.
Secondly, many systems which have C compilers have assem-
blers which accept characters like ".", "$" or "%" as being legi-
timate in identifiers, and often use them for distinguishing mac-
ros, system entry-point names or the like.
Thirdly, within the system libraries of these systems
these special characters are heavily used in just the same way as
the "." in the B system libraries: for unique identification of
entry points or routines which must NOT be used by normal "user"
programs. Within the library the functions which must get the
real scan call ".scan", while others call whatever function is
known by the name "scan" in that program. In fact, the character
used should probably be one which IS illegal in the language, to
keep the unwary from using it.
Therefore it behooves us to provide a way of referencing
these "funny" names in a legal C program. If not, we are effec-
tively saying that C should be restricted to Unix and Unix-like
systems only, and/or C programmers are to be larded with a re-
quirement that they sucessfully predict and avoid all names which
will ever be used in a "system" library.
Waterloo has a plausable mechanism for dealing with sys-
tem names on Honeywells: an "#equivalence <funny_name>
<legal_name>" statement, camoflaged as a preprocessor directive
so non-HW C compilers won't mistake if for either an error or
some sort of language extension. It was put in out of a real
need, to allow for referencing some of the 16-bit HW operating
systems' tables.
If there is a better method, let's hear about it! There
are lots of systems that C would be quite usefull on, so don't
let's be blinded by the ease of dealing with Unix into leaving
them to make do with Ada and COBOL.
--davegwyn@Brl-Vld.ARPA (03/30/83)
From: Doug Gwyn (VLD/VMB) <gwyn@Brl-Vld.ARPA> I missed some of this discussion, but I would like to point out that C can indeed be used successfully on non-UNIX systems. The best way to do this seems to be to have on hand a run-time library containing as many UNIX-compatible routines as possible: certainly stdio, and most of the other "section 3" routines. In turn, these routines can generally be written to use UNIX-like system interface calls when they need system services. I built an environment very like UNIX on a RSTS/E operating system in this way; the very same user interface can be provided on essentially any modern operating system. There is a well-established naming convention for externs that are in danger of being used unawares by a programmer: in C, prepend an underscore to "private system library" externs, use statics for externs that needn't be published, and only use non-underscore names in the documented run-time interface for general programmer use. (At assembly language level, the underscore may be mapped into some other character such as ., $, or in extreme emergency, Q8.)