Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ames!uhccux!munnari.oz.au!bruce!cechew
From: cechew@bruce.OZ (Earl Chew)
Newsgroups: comp.os.minix
Subject: Re: stdio
Message-ID: <1529@bruce.OZ>
Date: 13 Sep 89 09:39:46 GMT
References: <18971@princeton.Princeton.EDU>
Organization: Monash Uni. Computer Science, Australia
Lines: 77

I am about to post a much revised version of stdio. AST, I have sent you
numerous bits of mail with my address embedded within, but I haven't heard from
you. Is this because you didn't receive them, or the return address is still
wrong?

Some comments:

From article <18971@princeton.Princeton.EDU>, by nfs@notecnirp.Princeton.EDU (Norbert Schlenker):
> In article <1521@bruce.OZ> cechew@bruce.OZ (Earl Chew) writes:
>>From article <18952@princeton.Princeton.EDU>, by nfs@notecnirp.Princeton.EDU (Norbert Schlenker):
>>> + 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.

What I had originally meant was, "I don't know how useful it is to have fgetc
and fputc as macros". I haven't received my Posix stuff yet so I don't know
just how many of the macros have to have functions behind them. I have worked
on the assumption that all need to have macros. Are getc and putc exceptions?

>>> + Support for [rwa]+ modes in (f|fd|fre)open
> 
> Posix says you have to do this.  ANSI says you have to do this.  If a file

I have reworked my code (a little) to attempt to mimic this behaviour. Minix
(without Simon Poole's patches) does not currently support O_APPEND. This means
behaviour can be mimicked by calling lseek() before any write. This won't get
it quite right if two processes compete for access to the file since one
process may lseek() before the other gets a chance to write. Support for
O_APPEND is in my code also and it is compiled in if your fcntl.h indicates that
it is there.

>>> + ANSI additions to stdio
>>> 	fsetpos() / fgetpos()
> 
> Cousins to fseek() and ftell(), respectively.  That's how I implemented them.

Cousins -- how close? Do they have exactly the same calling sequence and the
same semantics?

>>> 	remove()
>>> 	rename() from Freeman Pascal
>>
> My feelings exactly.  But the ANSI standard says they belong there.
> So does perror(), by the way.

Inserted perror, remove and rename.

I have been having problems with the semantics of fdopen. What _should_ happen
in the following cases. Note that the question is not "What _does_ happen on
machine x in the following cases?"

1. if (fdopen(0, "r") == stdin)
     puts("Y");
   else
     puts("N");

   So what gets printed?

2. fclose(fdopen(0, "r"));
   len = read(0, buf, 1);

   Does the read succeed (ie is file descriptor 0 still active)?

3. fclose(fdopen(0, "r"));
   printf("%d\n", getchar);

   What gets printed by the printf? EOF? Is stdin still active?

4. for (; fdopen(0, "r") != NULL; ) ;

   Does the loop terminate? When?

Earl