Eric Sunshine <sunshine@xxxxxxxxxxxxxx> writes:
>> + 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?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html