Re: [exim-dev] patch: -Mset

Top Page
Delete this message
Reply to this message
Author: Philip Hazel
Date:  
To: John Jetmore
CC: exim-dev
Subject: Re: [exim-dev] patch: -Mset
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