Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cwjcc!gatech!udel!princeton!notecnirp!nfs
From: nfs@notecnirp.Princeton.EDU (Norbert Schlenker)
Newsgroups: comp.os.minix
Subject: Re: stdio
Summary: Competition!
Message-ID: <18952@princeton.Princeton.EDU>
Date: 8 Sep 89 11:59:33 GMT
Sender: news@princeton.Princeton.EDU
Reply-To: nfs@notecnirp.UUCP (Norbert Schlenker)
Organization: Dept. of Computer Science, Princeton University
Lines: 60


Well, well, a little competition.  Here am I trying to put together
my very own stdio for network distribution when along comes Earl
Chew's package.  It looks well done, it runs very fast - but I still
think mine is better.  Here are the high points of mine:

+ ANSI compatibility
	As far as I can tell (working from secondary sources like K&R2),
	and with the exception of various small items noted below, the
	package is ANSI compatible.  That includes prototypes when
	 __STDC__ is defined and (almost) no name space pollution.
+ POSIX compatibility
	The package is also POSIX compatible, with the limitations that
	no kernel changes allow.
+ New include files
	New header files per ANSI (except float.h, locale.h,  and math.h).
	Includes a working stdarg.h.  Updated versions of POSIX header
	files (but lots of work still to be done).
+ Support for fast / debugging stdio functions
	Default compile generates code that does lots of argument checking
	(default action is to return whatever failure code the function
	is supposed to).  Compiling with -DNDEBUG produces fast library.
+ Functions behind all macros
	Functions accessible if the macros in stdio.h/ctype.h are #undef'ed.
? Statically allocated FILEs
	+ John Vaudin's complaints are moot
	- Extra statically allocated storage (~200 bytes)
+ Support for [rwa]+ modes in (f|fd|fre)open
	Specifying "a" means that writes are always at end of file
	(special code included for the standard Minix, works automatically
	if Simon Poole's patches are applied to FS).
	Specifying "+" means both reads and writes are possible, but
	code is included to only allow a change after fseek() (I think
	this is ANSI, but haven't checked).
+ ANSI additions to stdio
	fsetpos() / fgetpos()
	remove()
	rename() from Freeman Pascal
+ getc()/putc() are macros
	But they're unsafe (i.e. they evaluate their arguments more than once).
+ fgetc()/putc() can be safe macros
+ ungetc() works once on unbuffered files
? Different semantics for gets()
	Non-null strings that end without '\n' at EOF don't return EOF.
+ Flushing tty output on tty input
	If stdout is attached to a tty, it is flushed before reads on stdin.
? Line buffering not implemented
	In my opinion, _IOLBF is a flawed concept.  ANSI says it has to
	be there, so the hooks are there (i.e. requests are honoured but
	subsequently ignored).  Adding support for it in fputc() is
	reasonably easy, but (in my opinion) a waste of time.

That's about it.  With my stdio, compiled with -DNDEBUG, times on Earl
Chew's tests are comparable to his code.  My debugging code is slower,
but it checks for more error conditions (than either the existing stdio
or Earl's).

I could use four or five beta testers.  Anyone want to volunteer?

Norbert