Re: syscall stubs

[Jim Meyering <jim at meyering dot net>]

Joern Rennecke wrote:
> Quoting Jim Meyering <jim@meyering.net>:
>
>> stat always succeeds.  Even with a very rudimentary file system, shouldn't
>>   stat be able to fail with ENOENT, EFAULT, ENAMETOOLONG, ENOTDIR, etc?
>>
>> fstat always succeeds.  What about EBADF, EFAULT, etc.?
>
>> link.c always fails with EMLINK;  wouldn't ENOSYS be better?
>> wait.c: likewise always with ECHILD;  wouldn't ENOSYS be better?
>>   Tools that detect lack of support recognize ENOSYS as indicating that.
>
> These minimal stubs agree with what the newlib documentation
> says at http://sourceware.org/newlib/ under 14.1 .
>
> Is that documentation wrong?

Hi Joern,

Hah!  I didn't even know about that documentation.

    http://sourceware.org/newlib/libc.html#Syscalls

IMHO, if there is a chance the stub code will ever be run, then those
sample functions should be improved.  Autoconf-like tools detect stubs by
their failing with ENOSYS, so a system with syscalls that are stubbed-out
in the expected manner will be easier to port to.  Similarly, if called,
it's a lot easier to understand that there's no fork support when it
fails with ENOSYS than with EAGAIN.  With the latter, an application
might simply retry (as recommended e.g., in glibc documentation),
waiting for the supposedly temporary problem to go away.

Obviously, it depends on what you want to do with the stub.  If it's
really just a place-holder, used so that you don't get link failures
in development, and no one (including configure-like scripts) will ever
call them, then it doesn't matter.  But the fact that they do set errno
and return an indication of failure implies to me that some caller will
actually act on those values.