From: utzoo!watmath!dcbrown@watbun
Newsgroups: net.unix-wizards
Title: Naming conventions for library functions
Article-I.D.: watmath.4695
Posted: Wed Mar  9 14:58:52 1983
Received: Thu Mar 10 03:56:17 1983

        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.
                                --dave