Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!ames!uhccux!munnari.oz.au!bruce!cechew
From: cechew@bruce.OZ (Earl Chew)
Newsgroups: comp.os.minix
Subject: Re: stdio
Message-ID: <1521@bruce.OZ>
Date: 8 Sep 89 23:05:14 GMT
References: <18952@princeton.Princeton.EDU>
Organization: Monash Uni. Computer Science, Australia
Lines: 109

From article <18952@princeton.Princeton.EDU>, by nfs@notecnirp.Princeton.EDU (Norbert Schlenker):
> 
> 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:

That's hardly surprising ;-)

> 
> + ANSI compatibility

I think that if you look at mine, you will also find that I've gone to some
trouble to include function prototypes and the like when __STDC__ is defined.
Some more work has been done on this since the last set of patches to get gcc
to make less noise.

> + POSIX compatibility

I'm not in a position to say how Posix compatible my stdio is since I haven't
received my copy of the standard yet :-(.

> + New include files

The only header files I have included is stdio.h. It's the only one needed to
get stdio running.

> + Support for fast / debugging stdio functions

Fast - but not much debugging.

> + Functions behind all macros

I don't know how useful this is. fgetc and fputc are function versions of putc
and getc, but other than that...

> ? Statically allocated FILEs
> 	+ John Vaudin's complaints are moot
> 	- Extra statically allocated storage (~200 bytes)

I have already posted saying that John Vaudin's complaints have been
addressed without the need to allocate anything that wasn't allocated in the
original posting. stdin, stdout and stderr are allocated at compile time (apart
from their buffers).

> + 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).

I'm not clear about this. Is it specifically stated in Posix that `a' mode will
always write at the end of the file? Does that mean that fseek() on a stream
opened in `a' mode will fail? I am about to put in code for three argument
opens which are supported by Simon Poole's patches. Are these going into 1.4b?

> 	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).

Done.

> + ANSI additions to stdio
> 	fsetpos() / fgetpos()

Haven't seen these before --- I'd better go find out what they do.

> 	remove()
> 	rename() from Freeman Pascal

Are these in stdio? Seems to me to be a strange place to put them. What has
remove() and rename() got to do with stream input and output?

> + fgetc()/putc() can be safe macros

I thought that fgetc and fputc were _meant_ to be functions. If you want macros
you can use getc and putc.

> + ungetc() works once on unbuffered files

Yes, already in there.

> ? Different semantics for gets()
> 	Non-null strings that end without '\n' at EOF don't return EOF.

gets() should return NULL on EOF --- I think that was a typo. Are the semantics
that different? These are the semantics according the manual page on the Sun
here. A simple test program shows that both stdios on the Pyramid and Sun
systems perform the same actions on non-null strings without a \n before the
EOF, ie don't return EOF unless the string is empty. My stdio follows the same
action.

> + Flushing tty output on tty input
> 	If stdout is attached to a tty, it is flushed before reads on stdin.

Yes. This is standard procedure although not done by the old Minix stdio.
Caused me some heartache once --- I thought my program had crashed when I
didn't see a prompt. I did eventually see the prompt --- after I had typed the
input :-(.

> ? Line buffering not implemented

Line buffering is implemented. It does cause complications but the thing is that
you don't want to have to put an explicit fflush() after all console messages.
Then again you don't want the (short) messages to be stuck in the buffer until
the program terminates. You could instead try for nobuffering at all or a short
buffer (which just about amounts to the same thing but could also suffer from
the same shortcomings as a largish buffer) but there is a dramatic difference,
especially on Minix, between line buffering and _no_ buffering. Try it and
see.

Earl