Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!njin!princeton!notecnirp!nfs
From: nfs@notecnirp.Princeton.EDU (Norbert Schlenker)
Newsgroups: comp.os.minix
Subject: Re: ANSI C etc
Summary: Some minor cavils
Message-ID: <22864@princeton.Princeton.EDU>
Date: 8 Jan 90 14:41:15 GMT
References: <5058@ast.cs.vu.nl>
Sender: news@princeton.Princeton.EDU
Reply-To: nfs@notecnirp.UUCP (Norbert Schlenker)
Organization: Dept. of Computer Science, Princeton University
Lines: 59

In article <5058@ast.cs.vu.nl| ast@cs.vu.nl (Andy Tanenbaum) writes:
|One item worth mentioning is the discussion started by Norbert on abort().
|Just to make sure everyone understands,
|  (1) Norbert's basic point is valid
|  (2) The abort() example chosen was not a good one.
|
|The standard specifically forbids programmers from defining any routines
|that are used in the standard.  Thus a program defining abort() is
|nonconforming and is not required to work.
|
|Nevertheless, read() is not defined in ANSI C, although it is defined in
|POSIX, about which the ANSI standard knows nothing.  If you define your
|own read(), you are perfectly within the standard, and you have every right
|to expect fread() to continue working.  Bet it won't.
|
|The ACK compiler is getting gradually smaller.  There is a good chance
|that we will be able to wedge it in there and be able to use it to compile
|all of MINIX in 64K + 64K.  The solution we will probably use is this.
|The real system calls will get and underscore.  Thus in the lib/posix
|directory you will find a file _read.c, which defines (in C) _read(), which
|calls 'callm1' to send the message.  It is my understanding that neither
|ANSI nor POSIX forbid implementers from adding new library routines as
|long as all the ones in the standards work correctly, i.e., there is no
|namespace pollution by the existence of callm1 in the library, or by
|the existence of a routine to compute bessel functions or anything else.

This doesn't quite work.  An application could easily have a function callm1()
and where does that leave the library?  Callm1() isn't a very likely name,
but len() certainly is!

I suggest the following variation.  Make a new header (I called mine
<lib/const.h>) which defines constants like:

#define __READ  __read		(or _read if you prefer)
#define __CALLM1 __call1	(relying on 8 character linker here)

Then <lib.h> should include <lib/const.h> and the library routines should
use __READ() and __CALLM1() to do their dirty work.  As for len(), it can
be renamed using this scheme, but I think a better solution is to replace
every instance of it with len(...) + 1.

|In addition, there will be a parallel directory, called POSIX (the old
|one being renamed _POSIX) containing routines like this, in assembler:
|
|..define read
|..globl _read
|read:  jmp _read

I have a script to do this mechanically.

|One of the nicest things about the new compiler is that the
|assembler and loader are split, and the loader won't
|run out of space on things the size of kermit.

When do we get it?? (pant, pant)

|Andy Tanenbaum (ast@cs.vu.nl)

Norbert