On Tue, Jun 05, 2012 at 11:30:34PM +0200, Joerg Sonnenberger wrote:
> On Wed, Jun 06, 2012 at 01:01:54AM +0400, Andrey Chernov wrote:
> > On Wed, Jun 06, 2012 at 06:11:01AM +1000, Bruce Evans wrote:
> > > This is essentially unusable (so a bad idea). Instead of unconditionally
> > > saving and res
On Wed, Jun 06, 2012 at 01:01:54AM +0400, Andrey Chernov wrote:
> On Wed, Jun 06, 2012 at 06:11:01AM +1000, Bruce Evans wrote:
> > This is essentially unusable (so a bad idea). Instead of unconditionally
> > saving and restoring errno around calls to free(), portable POSIX code
> > can soon use a
On Wed, Jun 06, 2012 at 06:11:01AM +1000, Bruce Evans wrote:
> This is essentially unusable (so a bad idea). Instead of unconditionally
> saving and restoring errno around calls to free(), portable POSIX code
> can soon use a messy ifdef to avoid doing this in some cases, but still
> has to do it
On Tue, 5 Jun 2012, Andrey Chernov wrote:
On Wed, Jun 06, 2012 at 04:57:29AM +1000, Bruce Evans wrote:
POSIX may require errno to not be clobbered, especially for its functions.
It probably shouldn't do this for Standard C library functions like free(),
since this would be an extension and any
On Wed, Jun 06, 2012 at 04:57:29AM +1000, Bruce Evans wrote:
> POSIX may require errno to not be clobbered, especially for its functions.
> It probably shouldn't do this for Standard C library functions like free(),
> since this would be an extension and any use of the extension would give
> unnece
On Tue, 5 Jun 2012, Andrey Chernov wrote:
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
On Tue, Jun 05, 2012 at 05:17:33PM +0200, Joerg Sonnenberger wrote:
> On Tue, Jun 05, 2012 at 06:31:14PM +0400, Andrey Chernov wrote:
> > 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
> > direc
On Tue, Jun 05, 2012 at 08:23:20AM -0700, Marcel Moolenaar wrote:
> If we the resolution of the ID 385 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)
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
On Tue, Jun 05, 2012 at 06:31:14PM +0400, Andrey Chernov wrote:
> 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).
The standard is quite irrelevant here. FreeBSD is free to
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
On Tue, Jun 05, 2012 at 05:13:05PM +0400, Andrey Chernov wrote:
> On Tue, Jun 05, 2012 at 02:55:20PM +0200, Joerg Sonnenberger wrote:
> > On Tue, Jun 05, 2012 at 04:39:01PM +0400, Andrey Chernov wrote:
> > > Moreover, standard metion "unsuccessful call" case for free() where errno
> > > state is t
On Mon, Jun 04, 2012 at 09:34:49PM +, Andrey A. Chernov wrote:
> 1) IEEE Std 1003.1-2008, "errno" section, is explicit that
>
> "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 mod
On Tue, Jun 05, 2012 at 03:10:06PM +0200, Dag-Erling Sm??rgrav wrote:
> Pawel Jakub Dawidek writes:
> > 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 functi
On Tue, Jun 05, 2012 at 02:55:20PM +0200, Joerg Sonnenberger wrote:
> On Tue, Jun 05, 2012 at 04:39:01PM +0400, Andrey Chernov wrote:
> > Moreover, standard metion "unsuccessful call" case for free() where errno
> > state is totally undefined.
>
> ...which would be a programming mistake in first
Pawel Jakub Dawidek writes:
> 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 succ
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 suc
On Tue, Jun 05, 2012 at 04:39:01PM +0400, Andrey Chernov wrote:
> Moreover, standard metion "unsuccessful call" case for free() where errno
> state is totally undefined.
...which would be a programming mistake in first place and is valid as
justification.
Joerg
__
On Tue, Jun 05, 2012 at 04:39:01PM +0400, Andrey Chernov wrote:
> > Actually, it says the following:
> >
> > RETURN VALUE
> >
> > The free() function shall not return a value.
> >
> > ERRORS
> >
> > No errors are defined.
> >
> > How much clearer do you want it? ;)
>
> It is p
On Tue, Jun 05, 2012 at 11:35:53AM +0300, Konstantin Belousov wrote:
> Not to mention that the patch was committed to _our_ implementation of
> libc, which uses _our_ free, and not some abstract free(3). Our free changing
> errno means that process state is so messed that worrying about realpath(3)
On Tue, Jun 05, 2012 at 10:08:09AM +0200, Dimitry Andric wrote:
> On 2012-06-04 23:34, Andrey A. Chernov wrote:> Author: ache
> > Date: Mon Jun 4 21:34:49 2012
> > New Revision: 236582
> > URL: http://svn.freebsd.org/changeset/base/236582
> >
> > Log:
> > 1) IEEE Std 1003.1-2008, "errno" sectio
On Tue, Jun 05, 2012 at 10:08:09AM +0200, Dimitry Andric wrote:
> On 2012-06-04 23:34, Andrey A. Chernov wrote:> Author: ache
> > Date: Mon Jun 4 21:34:49 2012
> > New Revision: 236582
> > URL: http://svn.freebsd.org/changeset/base/236582
> >
> > Log:
> > 1) IEEE Std 1003.1-2008, "errno" sectio
On 2012-06-04 23:34, Andrey A. Chernov wrote:> Author: ache
> Date: Mon Jun 4 21:34:49 2012
> New Revision: 236582
> URL: http://svn.freebsd.org/changeset/base/236582
>
> Log:
> 1) IEEE Std 1003.1-2008, "errno" section, is explicit that
>
> "The setting of errno after a successful call to
On Mon, Jun 04, 2012 at 09:34:49PM +, Andrey A. Chernov wrote:
> Author: ache
> Date: Mon Jun 4 21:34:49 2012
> New Revision: 236582
> URL: http://svn.freebsd.org/changeset/base/236582
>
> Log:
> 1) IEEE Std 1003.1-2008, "errno" section, is explicit that
>
> "The setting of errno after
Author: ache
Date: Mon Jun 4 21:34:49 2012
New Revision: 236582
URL: http://svn.freebsd.org/changeset/base/236582
Log:
1) IEEE Std 1003.1-2008, "errno" section, is explicit that
"The setting of errno after a successful call to a function is
unspecified unless the description of that func
25 matches
Mail list logo
