svn commit: r236582 - head/lib/libc/stdlib

[Andrey Chernov]

On Tue, Jun 05, 2012 at 09:47:42AM +0200, Pawel Jakub Dawidek wrote:
> >   "The setting of errno after a successful call to a function is
> >   unspecified unless the description of that function specifies that
> >   errno shall not be modified."
> 
> Very interesting. However free(3) is always successful. Maybe we need
> more context here, but the sentence above might talk about functions
> that can either succeed or fail and such functions do set errno on
> failure, but we don't know what they do to errno on success - they
> sometimes interact with the errno, free(3) never does.

According to Austing Group interpretation, this setence talks about 
funtions which always succeed too, please see
http://austingroupbugs.net/view.php?id=385

> I aware that my interpretation might be too wishful, but it is pretty
> obvious to save errno value when calling a function that can eventually
> fail - when we save the errno we don't know if it will fail or not, so
> we have to do that, but requiring to save errno when calling a void
> function that can't fail is simply silly and complicates the code
> without a reason.

It still can fail due to internal errors, it just not returns failure.
For internal errors POSIX states that errno state is unspecified.

> I agree that the standards aren't clear, but if saving errno around
> free(3) is the way to go, then I'm sure we have much more problems in
> our code, even if it is not suppose to be portable it should be correct
> - we never know who and when will take the code and port it.

Currently they are pretty clear in that moment, although I agree that if 
POSIX says it should not modify errno, the life will be easy. Lets look at 
their further movement, since they are already aware of this specific 
problem.

> I guess what I'm trying to say here is that this is much bigger change
> than it looks and we should probably agree on some global rule here.

...which not violate standards.

-- 
http://ache.vniz.net/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20120605/5d547f7b/attachment.pgp