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: <19057@princeton.Princeton.EDU>
Date: 13 Sep 89 21:11:32 GMT
References: <18971@princeton.Princeton.EDU> <1529@bruce.OZ>
Sender: news@princeton.Princeton.EDU
Reply-To: nfs@notecnirp.UUCP (Norbert Schlenker)
Organization: Dept. of Computer Science, Princeton University
Lines: 80

In article <1529@bruce.OZ> cechew@bruce.OZ (Earl Chew) writes:
>...
>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
...
ANSI requires that every function defined as being in the standard library
must be implemented as a function.  If you want to implement some standard
functions as safe macros, that's OK, but the function still has to be
available.  Any user must be able to get at the function by #undef'ing the
macro name or taking the address of the function name (I haven't tried this,
but I bet the ACK compiler won't manage the last one).

>>>> + Support for [rwa]+ modes in (f|fd|fre)open
>
>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.

I hadn't thought of the problem with shared file descriptors.  This is
not even a little bit nice.  My code will have the same problem.

>>>> + ANSI additions to stdio
>>>> 	fsetpos() / fgetpos()
...
int fgetpos(FILE *stream, fpos_t *pos);
	Stores the current value of the file position in *pos.
int fsetpos(FILE *stream, fpos_t *pos);
	Sets the file position for the stream to that defined by *pos.

My code just has a typedef long fpos_t and appropriate macros that
invoke ftell() and fseek().
...
>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?

Whatever you like.  Posix doesn't say "shall" or "should" or "must", so 
do whatever you want.

>2. fclose(fdopen(0, "r"));
>   len = read(0, buf, 1);
>
>   Does the read succeed (ie is file descriptor 0 still active)?

No.  ANSI says that fclose() closes the file, not just the stream
associated with it.

>3. fclose(fdopen(0, "r"));
>   printf("%d\n", getchar);
>
>   What gets printed by the printf? EOF? Is stdin still active?

Surely you mean getchar().  As for the questions, here's my opinion:
The file is closed, but stdin looks like a valid stream (assuming
that the answer to question 1 above is no).  The getchar() should
return EOF, so printf() should print it.

>4. for (; fdopen(0, "r") != NULL; ) ;
>
>   Does the loop terminate? When?

Depends on the answer to 1 again.  I think it should terminate after
FOPEN_MAX streams have been opened.

>Earl

Norbert