Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!mcgill-vision!bloom-beacon!eru!luth!sunic!tut!santra!mcsun!hp4nl!star.cs.vu.nl!ast@cs.vu.nl
From: ast@cs.vu.nl (Andy Tanenbaum)
Newsgroups: comp.os.minix
Subject: ANSI C etc
Message-ID: <5058@ast.cs.vu.nl>
Date: 7 Jan 90 15:26:13 GMT
Sender: ast@cs.vu.nl
Organization: Fac. Wiskunde & Informatica, VU, Amsterdam
Lines: 52


I have just managed to dig out from the worst of the email that came in 
during the vacation, when I didn't process it mutliple times a day, as usual.
Thus I am somewhat behind in reacting to the news.

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.

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

For each POSIX call there will be a 3-line routine like this that is the
one called by user programs.  Things like fopen, stdio in general etc will
use _read, and will continue to work if you provide your own read()
routine.  We can probably mechanically generate all the 3-line assembly
routines from the POSIX/*.c files since the contents is a simple macro.
The overhead is 1 instruction per call.  I can live with that.

Any comments on this scheme?

Has anybody been able to compile kermit (probably by using some other
compiler)?  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.

Andy Tanenbaum (ast@cs.vu.nl)