ast@cs.vu.nl (Andy Tanenbaum) (01/07/90)
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)
nfs@notecnirp.Princeton.EDU (Norbert Schlenker) (01/08/90)
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
nfs@notecnirp.Princeton.EDU (Norbert Schlenker) (01/08/90)
In article <22864@princeton.Princeton.EDU> nfs@notecnirp.UUCP (Norbert Schlenker) writes: > 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. I meant "strlen(...) + 1".
henry@utzoo.uucp (Henry Spencer) (01/12/90)
In article <5058@ast.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: >... 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. That's correct. So long as a user can write a program which defines a function foo() for its own purposes, and still be able to use all the standard functions and have them work, there is no prohibition on having a non-standard function named foo() available in a library as well. (Note that if you want to supply a prototype for it in a header file, you can't put it in one of the standard header files unless you play tricks, because the prototype would interfere with the user defining his own.) -- 1972: Saturn V #15 flight-ready| Henry Spencer at U of Toronto Zoology 1990: birds nesting in engines | uunet!attcan!utzoo!henry henry@zoo.toronto.edu