msvcrt: Fix EOF behavior on read from pipe

[Dan Kegel]

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.

> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pipe2.patch
Type: text/x-patch
Size: 4738 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20080209/00d86a7a/attachment-0001.bin