standards/186028: incorrect return values for posix_fallocate()

Konstantin Belousov kostikbel at gmail.com
Thu Jan 30 17:52:37 UTC 2014


On Sat, Jan 25, 2014 at 06:46:16AM +1100, Bruce Evans wrote:
> I think it is better to not preserve errno, but to intentionally clobber
> it to the same value as madvise() does.  Its value is unspecified, and
> it is better to set it to new garbage than old garbage in case the
> application doesn't understand POSIX's suprising error handling.  This
> follows from C's specification of errno and POSIX's not saying anything
> about errnor for posix_madvise().  From a C99 draft:
> 
>         [#3]  The  value of errno is zero at program startup, but is
>         never set to zero by any library function.159)  The value of
>         errno  may  be  set  to  nonzero  by a library function call
>         whether or not there is an error, provided the use of  errno
>         is not documented in the description of the function in this
>         International Standard.
> 
> So any library function can set errno to any nonzero value other than
> 0, unless it is specifically documented to not do so.  stdio
> (__smakebuf()) setting errno to ENOTTY on success in most cases (by
> calling isatty() on a non-terminal) a classic example, and
> posix_madvise() should be no different, with more reason than stdio.
> 
> In the above, you preserve errno on failure but don't explicitly
> preserve it on sucess.  madvise() doesn't clobber it on success, but
> this is an implementation detail.  For most functions, errno becomes
> garbage on success.
Yes, this is question of quality.  posix_madvise(2) should behave like
a syscall.

> The man pages emphasize not setting errno too much.  This matches your
> implementation (assuming the undocmented behaviour that madvise() doesn't
> modify errno on success), but applications shouldn't depend on this.

I document the implementation.  If somebody could provide the better
wording, I cannot object.

For now, I am going to commit the existing patch.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-standards/attachments/20140130/83663b44/attachment.sig>


More information about the freebsd-standards mailing list