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/
pgpaMiikMNPHJ.pgp
Description: PGP signature