Re: [PATCH] mingw: emulate write(2) that fails with a EPIPE

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 16, 2015, 20:36 UTC
Message-ID: <xmqqmvtacere.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CAPig+cQzCHtyVs47=ASs5V2BSV7gpVszbdTFydiRhnz3gtD2Qw@mail.gmail.com>

Eric Sunshine <sunshine@sunshineco.com> writes:

Show 14 quoted lines

>> +       if (result < 0 && errno == EINVAL && buf) {
>
> Here, errno is EINVAL...
>
>> +               /* check if fd is a pipe */
>> +               HANDLE h = (HANDLE) _get_osfhandle(fd);
>> +               if (GetFileType(h) == FILE_TYPE_PIPE)
>> +                       errno = EPIPE;
>> +               else
>> +                       errno = EINVAL;
>
> Does any of the code between the outer 'if' and this point clobber
> errno, or are you merely assigning EINVAL for robustness against
> future changes?

I do think it is a good idea to reassign 'errno' here to stress on the fact that we return EPIPE only when we positively know that we were reading from a pipe, and otherwise we won't change the original errno at all.

But at the same time, if other things that are called before we figure out if we were reading from a pipe could affect errno, I wonder if that is an indication of a bug--an error return from system functions that the code is not responding to. For example, can _get_osfhandle() fail and when it does what would we see? Perhaps NULL in h?