msvcrt: Fix EOF behavior on read from pipe

[Damjan Jovanovic]

On Feb 9, 2008 5:27 PM, Dan Kegel <dank at kegel.com> wrote:
> On Feb 9, 2008 2:15 AM, Damjan Jovanovic <damjan.jov at gmail.com> wrote:
> > > Try my patch, it should help that case.
> >
> > It only helps if I change
> > +            if (type != FILE_TYPE_PIPE) {
> > to
> > +            if (type != FILE_TYPE_PIPE && type != FILE_TYPE_CHAR) {
>
> That makes me as uneasy as I bet it does you; switching to
> detecting EOF by noticing zero byte reads as you suggested sounds safer.
> Try the attached patch and let me know what you think.

It works with jdb, and all msvcrt tests still pass. I was trying the
same thing a while back, but some tests always kept failing, so well
done!

> > Well, if the MSDN is correct about ReadFile() returning only when the
> > requested number of bytes is read unless an error occurs (it's a big
> > if :-), then it would be an NTDLL NtReadFile() issue where pread()
> > returns too soon due to a signal. But I haven't been able to get a
> > signal to interrupt pread() in my tests, maybe wine handles signals.
>
> Wine's ReadFile already tries to handle interrupted reads, but it looks
> offhand like it only handles the case where the read is interrupted
> before getting any bytes.
> Wine uses signals internally, maybe a stress test that tickled
> that part of wine heavily while doing lots of extremely large ReadFile() calls
> would cause a partial read.  But it's possible that no apps would care,
> especially if we get rid of the "short read = EOF" bug you pointed out
> in msvcrt.
> - Dan
>

Thank you
Damjan