Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 5 Jun 2012 08:23:20 -0700
From:      Marcel Moolenaar <marcel@xcllnt.net>
To:        Andrey Chernov <ache@FreeBSD.org>
Cc:        svn-src-head@FreeBSD.org, Dimitry Andric <dim@FreeBSD.org>, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Joerg Sonnenberger <joerg@britannica.bec.de>
Subject:   Re: svn commit: r236582 - head/lib/libc/stdlib
Message-ID:  <9BD2A226-4C65-4879-8C6F-4C3AFF1C9D41@xcllnt.net>
In-Reply-To: <20120605143114.GA15710@vniz.net>
References:  <201206042134.q54LYoVJ067685@svn.freebsd.org> <4FCDBE69.6080906@FreeBSD.org> <20120605123901.GA13306@vniz.net> <20120605125520.GA12045@britannica.bec.de> <20120605131305.GF13306@vniz.net> <20120605142510.GB13416@britannica.bec.de> <20120605143114.GA15710@vniz.net>

next in thread | previous in thread | raw e-mail | index | archive | help

On Jun 5, 2012, at 7:31 AM, Andrey Chernov wrote:

> On Tue, Jun 05, 2012 at 04:25:10PM +0200, Joerg Sonnenberger wrote:
>>> Please see 
>>> http://austingroupbugs.net/view.php?id=385
>> 
>> That is about explicitly recognizing how stupid the notion of free(3)
>> not preserving errno is. Seriously, before you start to randomly bloat
>> code all over the place, restricting the behavior of free(3) to be
>> sensible is a much saner option.
> 
> I agree that saving errno inside free() itself will make life easy, 
> but I just follow their recommendation:
> 
> "However, earlier versions of this standard did not require this, and the
> same example had to be written as:
> 
>    // buf was obtained by malloc(buflen)
>    ret = write(fd, buf, buflen);
>    if (ret < 0) {
>        int save = errno;
>        free(buf);
>        errno = save;
>        return ret;
>    }
> "
> 
> All we have now is "earlier version of this standard". Until they'll 
> publish the future version, we can't ignore the recommendation.
> 
> BTW, if general consensus will be to track unpublished standard, I will 
> back out my change (in hope our malloc() maintainer will change free() to 
> directly save errno).

We do know where things are heading towards, so it seems very reasonable
to not change our current code, even if it is not in compliance with the
currently published version (or the "earlier version of this standard"
as you call it in the context of the unpublished version) and wait until
we have more clarity. Often times our code has been non-compliant for
many years and our non-compliance is shared with many implementations,
so I see little reason to push for an immediate compliancy.

If we the resolution of the ID 0000385 indicates that a future version
will have the suggested text, then one can definitely argue that it's
not unreasonable to start changing our functions to match the new text
(like free(3)) and change all consumers to depend on it.

I do not see a reason to revert the change under discussion just yet as
it just adds to the churn without there being anything concrete, but I
do suggest we won't "fix" any other code in the mean time. Our time is
probably better spent auditing our source base and documenting where we
depend on the yet-to-be-published behaviour and where we are strictly
in compliance with the current version. This can will help us in the
future when we want to clean things up.

Just my $0.02,


-- 
Marcel Moolenaar
marcel@xcllnt.net





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9BD2A226-4C65-4879-8C6F-4C3AFF1C9D41>