On Tue, 24 Oct 2006, John Jetmore wrote:
> On Tue, 24 Oct 2006, Philip Hazel wrote:
>
> > I have applied and slightly modified this patch. It also turns out that
> > with only a very small number of added code lines I was able to
> > implement an option that reads a message from an ordinary file (sort of
>
> I was playing with this and I ran into an issue that I don't fully
> understand and which appears to be Mac OS X specific.
Many thanks for playing! This might well have gone unnoticed for a long
time otherwise.
> (void)dup2(save_stdin, 0);
> (void)close(save_stdin);
> +if (feof(stdin)) {
> + fprintf(stderr, "stdin _is_ at eof()\n");
> + clearerr(stdin);
> +} else {
> + fprintf(stderr, "stdin is _not_ at eof()\n");
> +}
Looks me as if the dup'ing and then closing the 'other' fd is having the
(to me, unexpected) effect of marking the copied fd as "at eof".
However, I too am no expert at this level of system call. I do know,
however, that on systems I've used (Solaris, Linux), you can usually
read "beyond" eof on terminal input without using clearerr(). That is,
you can type ^D and the program will see "eof", but if it reads again
you can type more. My guess is that this is different on Darwin. I
predict you'll need clearerr(). And of course, we are also dealing with
the interaction of the system with the C input/output library.
It seems to me that there's no harm in calling clearerr()
unconditionally. On the other hand, re-reading the man page for "dup",
it may be that I shouldn't have used "close" there. Please can you test
by removing that "close" call?
Philip
--
Philip Hazel University of Cambridge Computing Service
Get the Exim 4 book: http://www.uit.co.uk/exim-book
