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: stdio
Message-ID: <18971@princeton.Princeton.EDU>
Date: 9 Sep 89 03:09:08 GMT
References: <18952@princeton.Princeton.EDU> <1521@bruce.OZ>
Sender: news@princeton.Princeton.EDU
Reply-To: nfs@notecnirp.UUCP (Norbert Schlenker)
Organization: Dept. of Computer Science, Princeton University
Lines: 125

In article <1521@bruce.OZ> cechew@bruce.OZ (Earl Chew) writes:
>From article <18952@princeton.Princeton.EDU>, by nfs@notecnirp.Princeton.EDU (Norbert Schlenker):

Let me state up front that I have access only to unofficial versions of
the ANSI C standard (like K&R 2nd edition).  If I'm wrong about what I
write, I'd like to be corrected.  If you have answers to some of the
questions posed below, please email me.

I do have a copy of the Posix standard.  Integrating it into my fuzzy
notion of the C standard has been an interesting experience.

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

I admit I've gone a bit overboard with the include files.  But I figured
that if I had to go through all the ANSI/Posix pain for stdio.h, I might
as well do the whole thing.

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

ANSI says you gotta do this.  It must be possible for a user to #undef
a standard library function's name and still have things work.

>> + 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?

Posix says you have to do this.  ANSI says you have to do this.  If a file
is opened for append, any write() goes at the end of the file.  I'm not
sure whether fseek() fails - it might just be ignored for normal "a" mode.
That's what I did.  (Question: What does X3J11 require?)  For "a+" mode,
fseek() has to seek.  As an aside, Posix says that the underlying lseek()
in such a case works normally (i.e. it sets the file pointer according to
what the user requested).  But any subsequent write() resets the file
pointer to the current end of file.  Simon Poole's patches seemed to do
this correctly, but I haven't looked closely.

I second Earl's request for information on whether 1.4b will address this.
From ast's summary posting, it looks like 1.4b is a bunch of patches at
the command level, just like 1.4a, so I suspect the answer is NO.

>> + ANSI additions to stdio
>> 	fsetpos() / fgetpos()
>
>Haven't seen these before --- I'd better go find out what they do.

Cousins to fseek() and ftell(), respectively.  That's how I implemented them.

>> 	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?

My feelings exactly.  But the ANSI standard says they belong there.
So does perror(), by the way.

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

Well, my reading of the standard is that any function can be implemented as
a safe macro.  Some functions are explicitly given license to be done as
unsafe macros (like getc/putc).  Since there is a performance hit for using
functions, I thought it might be nice to have the option.

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

(Question: What does the C standard say?)  I don't know what to make of this.
The systems to which I have access are BSD'ish and gets() doesn't return
EOF unless it's at EOF and it got exactly 0 characters.  But the old
stdio didn't act that way.  I have matched the BSD/Chew semantics; I just
don't know whether it's right.  And I thought I'd better say so.

>> ? Line buffering not implemented
>
>Line buffering is implemented. It causes 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.

Well, I've thought about this a little more and can understand that point
of view.  Now, if we could just get people to stop writing programs that
dumped core or went into infinite loops, we wouldn't need _IOLBF -:)  As
that seems a little unlikely, I suppose I'll put the code in. (Sounds of
me throwing a tantrum should be interpolated here.)  This wouldn't bother
me so much if there was a performance hit only for _IOLBF streams; the
point is that the code has to check everywhere, especially in the putc()
macro that I worked at so hard to make fast!

>Earl

Before this turns into a war, let me say that this exchange is going to
improve both of our stdio packages.  So far, Earl's package has gotten
me to dynamically allocate the buffers for stdin and stdout, an addition
that I think is worthwhile.  My notes above will probably goad Earl into
improvements for his code too.  Thanks a bunch.

Goads from Earl and others gratefully received.

Norbert