Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!snorkelwacker!usc!wuarchive!udel!princeton!notecnirp!nfs
From: nfs@notecnirp.Princeton.EDU (Norbert Schlenker)
Newsgroups: comp.os.minix
Subject: Re: Zen and the Art of Library Programming
Message-ID: <22700@princeton.Princeton.EDU>
Date: 3 Jan 90 03:25:45 GMT
References: <22630@princeton.Princeton.EDU> <830@prles2.UUCP>
Sender: news@princeton.Princeton.EDU
Reply-To: nfs@notecnirp.UUCP (Norbert Schlenker)
Organization: Dept. of Computer Science, Princeton University
Lines: 57

In article <830@prles2.UUCP> meulenbr@cst.prl.philips.nl (Frans Meulenbroeks) writes:
>In article <22630@princeton.Princeton.EDU> nfs@notecnirp.UUCP (Norbert Schlenker) writes:
>>Every (!) library function becomes a simple front-end for another function
>>which does the work.  Every library function can call ONLY the underlying
>>functions (I like to call them underware :-)  To avoid ANSI namespace
>>conflicts, I suggest the underware's names be prefixed with two underscores.
>
>I like the idea & hate the performance loss.

The performance loss can be made very minor.  The simplest way is to change
the headers so that every library function has a corresponding macro, and
the macros themselves call the underware functions.  I personally disapprove
strongly of this, because of the increased complexity of the headers, but
the possibility exists.

Another possibility, to which I alluded in my original posting, is to use
the posted peephole optimizer to turn something like:

unsigned int alarm(seconds)
unsigned int seconds;
{
  return __alarm(seconds);
}

into (in alarm.s):

jmp ___alarm

The code generated by cc for alarm() and other front-end routines is very
easy to recognize, and the peephole optimizer would have no trouble making
such a substitution.

A third possibility that springs instantly to mind is the abolition
of callm1() and callm3() in favour of macros.  They have to go anyway,
because of their namespace pollution (along with len() and send() and ...).
That compensates for the level added by the ANSIfication.

>One potential problem exists: 
>implementations may restrict the significance of an identifier to 6
>characters, and may ignore case distinctions. (ansi draft sec. 3.1)
>I don't know if this applies to minix, but if so, name clashes might
>occur by prepending the names with __
>(eg fputc and fputs could become __fput).

Granted.  This is already a problem with Minix, since asld only uses
eight characters.  My original proposal hid the __* names in a header,
with them replaced in the library code by macros like LIB_ALARM.  (Upon
further thought, I believe it would be better to use macros of the
form __ALARM for alarm()'s underware routine.)  Then the header writer
has to be cognizant of name space collisions, but the problem doesn't
arise elsewhere.

>Frans Meulenbroeks        (meulenbr@cst.prl.philips.nl)
>	Centre for Software Technology
>	( or try: ...!mcvax!phigate!prle!cst!meulenbr)

Norbert