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: Zen and the Art of Library Programming
Summary: Hmmm
Message-ID: <22759@princeton.Princeton.EDU>
Date: 4 Jan 90 02:07:00 GMT
References: <7259@nigel.udel.EDU> <22702@princeton.Princeton.EDU> <28591@amdcad.AMD.COM>
Sender: news@princeton.Princeton.EDU
Reply-To: nfs@notecnirp.UUCP (Norbert Schlenker)
Organization: Dept. of Computer Science, Princeton University
Lines: 37

In article <28591@amdcad.AMD.COM> tim@amd.com (Tim Olson) writes:
| After a lengthy quote from <22702@princeton.Princeton.EDU> and
|			     <7259@nigel.udel.EDU>, parts of which follow:
|| >This is a valid ANSI C program which should terminate with a SIGABRT
|| >signal.
|
|No, it isn't valid.
|| The compiler should compile the program without error or warning, because
|| the program has no errors in it.
|
|Yes, it does have an error (see below):
|
|| The point is that the assert() macro has
|| a guaranteed effect (according to ANSI), and the last part of that effect
|| is to terminate the program by calling the abort() function.  The abort()
|| function cited by ANSI is that of the ANSI standard, not a programmer
|| supplied one (i.e. ANSI expects the program to die after assert(0==1)).
|| A C compiler/library/linker combination that can't do this is BROKEN.
|
|This is not correct.  The program is erroneous because it defines an
|identifier with the same name as an identifier that is reserved
|(namely abort).  The behavior of the program is undefined.  See
|Section 4.1.2.1 (Reserved Identifiers).
|
|	-- Tim Olson

Quite right - thanks for pointing this out.  So __assert() can be left
as originally posted by Andy Tanenbaum.  Mea culpa ...

There is still a problem with a great deal of library code, however.
None of the Minix (Unix) system calls are currently valid for use by
the library.  Although abort() is reserved by ANSI, write() [for example]
is not.  So an ANSI fwrite() cannot use a POSIX write() - it will have to
use some underlying function like __write().  And the bottom Minix level
(callm1/callm3/len/sendrec/begsig/etc.) certainly has to be fixed.

Norbert