Switches the errno check from EINVAL to EFAULT

[0xdfc]

Leaving this here for my future evaluation and for the sake of argument, all manual references are from ARM based OS X:

The manual of errno says the following:

• 14 EFAULT Bad address. The system detected an invalid address in attempting to use an argument of a call.
• 22 EINVAL Invalid argument. Some invalid argument was supplied. (For example, specifying an undefined signal to a signal or kill function).

So. Both have a right to exist as valid error numbers for the test case. That being said, in multiple locations I've seen reference to the fact that when syscall to sys_write occurs, if a negative number is returned, it should be considered as the error code.

If we refer to the manual of write, we can see that EFAULT fits under the test case:

• [EFAULT] Part of iov or data to be written to the file points outside the process's allocated address space.

It fits under the test case because "iov or data" (iov is outside of our scope but data isn't) and NULL is of course outside of the process's allocated address space.

If we have a further look at EINVAL: "[EINVAL] The pointer associated with fildes is negative". We can see a somewhat confusing reference to the pointer associated with filedes being negative, perhaps they are referring to something internal, not sure. But it seems wrong to consider NULL a negative address.

Then there is one other mention for another error case which produces EINVAL: "[EINVAL] The value provided for nbyte exceeds INT_MAX." Which to us is irrelevant in the context of this case.

So as a result, there seems to be no viable way for write to be producing this errno as per the test case mentioned by @JonathanDUFOUR in #3.

My possibly incorrect guess as to why @xtrm-en ended up using EINVAL: as per the POSIX IEEE 1003.1 standard (link to a draft as most seem to be paywalled) - pipes (which are being used to test write) have no offset associated with them and as per line 69801 (EINVAL case for pwrite()), it is plausible that seeing an invalid buffer the instructions decided to check for an offset.

tl;dr: To be honest I struggle to find the reasoning behind the introduction of the EINVAL test case. I have arguments above for EFAULT. I don't have them for EINVAL.

[xtrm-en]

I'd argue the checks should be rewritten by comparing with the actual syscalls/libc implementation directly, since they might differ on some systems. I picked EINVAL simply because that's what my system was returning here, but it seems it's a more complicated matter.

[0xdfc]

Hmm agreed, as I initially said both general definitions from errno seem completely valid, I sadly saw your full PR after I had done some research and posted this. I completely agree with you that it should be on a per system basis.