[Bug libc/12515] New: clock() does not provide the advertised precision

[Bug libc/12515] New: clock() does not provide the advertised precision

[stephane at magnenat dot net]

http://sourceware.org/bugzilla/show_bug.cgi?id=12515

           Summary: clock() does not provide the advertised precision
           Product: glibc
           Version: 2.12
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
        AssignedTo: drepper.fsp@gmail.com
        ReportedBy: stephane@magnenat.net


Created attachment 5263
  --> http://sourceware.org/bugzilla/attachment.cgi?id=5263
Test case that compares clock() with gettimeofday()

On Ubuntu Linux 10.10 with glibc 2.12.1-0ubuntu10.2, the clock() function, from
<time.h> has an advertised precision of 1 us (CLOCKS_PER_SEC == 1000000l). Yet,
the return value only increments every 10 ms. This low precision is very
inconvenient, especially as higher-level utilities such as boost::timer uses
it. This is not a system-level problem, because gettimeofday() returns a much
higher precision (see attached test case).

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/12515] clock() does not provide the advertised precision

[stephane at magnenat dot net]

http://sourceware.org/bugzilla/show_bug.cgi?id=12515

Stéphane Magnenat <stephane at magnenat dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |stephane at magnenat dot
                   |                            |net

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/12515] clock() does not provide the advertised precision

[schwab@linux-m68k.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=12515

Andreas Schwab <schwab@linux-m68k.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID

--- Comment #1 from Andreas Schwab <schwab@linux-m68k.org> 2011-02-24 12:45:46 UTC ---
clock returns processor time, gettimeofday returns wall clock time, they are
completely different interfaces.  Use clock_getres/clock_gettime for a modern
interface with advertised precision.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/12515] clock() does not provide the advertised precision

[stephane at magnenat dot net]

http://sourceware.org/bugzilla/show_bug.cgi?id=12515

Stéphane Magnenat <stephane at magnenat dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |
     Ever Confirmed|1                           |0

--- Comment #2 from Stéphane Magnenat <stephane at magnenat dot net> 2011-02-24 12:52:10 UTC ---
Thank you for your quick answer!

I see the difference. Could it still be possible to make the "legacy"
interface, clock(), to provide a higher precision than what it does now? Maybe
by building it on top of clock_gettime(CLOCK_PROCESS_CPUTIME_ID, ...)? For
normal people, it is very inconvenient that "simple" calls do not provide high
resolution. As I said, it is a bit sad to have to re-implement boost::timer().
Of course, one could say that it is boost's problem, but as clock() is the
simple C interface, it would be nice for it to provide the maximum available
precision, that would make normal users happy :-)

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/12515] clock() should provide better precision

[stephane at magnenat dot net]

http://sourceware.org/bugzilla/show_bug.cgi?id=12515

Stéphane Magnenat <stephane at magnenat dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2011.02.24 12:58:42
            Summary|clock() does not provide    |clock() should provide
                   |the advertised precision    |better precision
     Ever Confirmed|0                           |1
           Severity|normal                      |enhancement

--- Comment #3 from Stéphane Magnenat <stephane at magnenat dot net> 2011-02-24 12:58:42 UTC ---
I am setting this bug as an enhancement and changing its title.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/12515] clock() should provide better precision

[schwab@linux-m68k.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=12515

Andreas Schwab <schwab@linux-m68k.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID

--- Comment #4 from Andreas Schwab <schwab@linux-m68k.org> 2011-02-24 13:27:56 UTC ---
The precision of clock is defined by the kernel and cannot be changed.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/12515] clock() should provide better precision

[stephane at magnenat dot net]

http://sourceware.org/bugzilla/show_bug.cgi?id=12515

Stéphane Magnenat <stephane at magnenat dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |
     Ever Confirmed|1                           |0

--- Comment #5 from Stéphane Magnenat <stephane at magnenat dot net> 2011-02-24 13:34:04 UTC ---
Sorry, probably I missed something, but why couldn't one use the value returned
by clock_gettime(CLOCK_PROCESS_CPUTIME_ID, ...) to implement clock()? One can
measure the time when the program starts, and then compute the difference to
implement a high-precision clock(). I do not know the details of the posix/C
specification, but I do not see any obstacle to improving the precision of
clock(), given that there already exist calls that provide this precision.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/12515] clock() should provide better precision

[schwab@linux-m68k.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=12515

Andreas Schwab <schwab@linux-m68k.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID

--- Comment #6 from Andreas Schwab <schwab@linux-m68k.org> 2011-02-24 13:41:43 UTC ---
That is a different clock.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/12515] clock() should provide better precision

[bugdal at aerifal dot cx]

http://sourceware.org/bugzilla/show_bug.cgi?id=12515

Rich Felker <bugdal at aerifal dot cx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
   Last reconfirmed|2011-02-24 12:58:42         |2013-04-19
                 CC|                            |bugdal at aerifal dot cx
         Resolution|INVALID                     |
     Ever Confirmed|0                           |1

--- Comment #7 from Rich Felker <bugdal at aerifal dot cx> 2013-04-19 02:58:20 UTC ---
I think this bug should be revisited. As far as I can tell, the
CLOCK_PROCESS_CPUTIME_ID clock is a valid implementation of clock(), and unlike
the legacy times() approach, it actually provides useful information. If this
bug is to be closed again, the closure should be accompanied by a citation
explaining why CLOCK_PROCESS_CPUTIME_ID is not a conforming implementation of
clock().

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/12515] clock() should provide better precision

[siddhesh at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=12515

Siddhesh Poyarekar <siddhesh at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |ASSIGNED
                 CC|                            |siddhesh at redhat dot com
         AssignedTo|drepper.fsp at gmail dot    |siddhesh at redhat dot com
                   |com                         |

--- Comment #8 from Siddhesh Poyarekar <siddhesh at redhat dot com> 2013-04-19 03:07:28 UTC ---
I'm going to say amen to this and work on it.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/12515] clock() should provide better precision

[siddhesh at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=12515

Siddhesh Poyarekar <siddhesh at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |SUSPENDED
         AssignedTo|siddhesh at redhat dot com  |unassigned at sourceware
                   |                            |dot org

--- Comment #9 from Siddhesh Poyarekar <siddhesh at redhat dot com> 2013-05-10 12:38:08 UTC ---
It's not as simple as I thought.  CLOCK_PROCESS_CPUTIME_ID will give a
timestamp and we will have to make our own estimate of what the amount of time
spent on the processor is.  I don't think there's a good way to get an initial
timestamp from userspace - the kernel is the best place to get us that.

I don't think there is a clean way to implement this outside of the kernel
without the kernel providing the necessary interface.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/12515] clock() should provide better precision

[siddhesh at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=12515

Siddhesh Poyarekar <siddhesh at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|SUSPENDED                   |NEW

--- Comment #10 from Siddhesh Poyarekar <siddhesh at redhat dot com> 2013-05-10 12:39:01 UTC ---
Oops, accidentally suspended this.  I'm leaving this as NEW, but I think it
should be closed until a proper kernel interface is available.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/12515] clock() should provide better precision

[bugdal at aerifal dot cx]

http://sourceware.org/bugzilla/show_bug.cgi?id=12515

--- Comment #11 from Rich Felker <bugdal at aerifal dot cx> 2013-05-10 13:20:44 UTC ---
Siddhesh, I don't get what you're saying at all. Could you clarify? I suspect
one of us has a serious misunderstanding of CLOCK_PROCESS_CPUTIME_ID.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/12515] clock() should provide better precision

[bugdal at aerifal dot cx]

http://sourceware.org/bugzilla/show_bug.cgi?id=12515

--- Comment #12 from Rich Felker <bugdal at aerifal dot cx> 2013-05-10 13:21:00 UTC ---
Siddhesh, I don't get what you're saying at all. Could you clarify? I suspect
one of us has a serious misunderstanding of CLOCK_PROCESS_CPUTIME_ID.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/12515] clock() should provide better precision

[siddhesh at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=12515

Siddhesh Poyarekar <siddhesh at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
         AssignedTo|unassigned at sourceware    |siddhesh at redhat dot com
                   |dot org                     |

--- Comment #13 from Siddhesh Poyarekar <siddhesh at redhat dot com> 2013-05-10 13:27:54 UTC ---
That would be me.  It occurred to me that I had assumed that
CLOCK_PROCESS_CPUTIME_ID doesn't start from 0 at process start and I found out
I was wrong.  Taking it back, sorry for the noise.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/12515] clock() should provide better precision

[siddhesh at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=12515

Siddhesh Poyarekar <siddhesh at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #14 from Siddhesh Poyarekar <siddhesh at redhat dot com> ---
Pushed to master:

commit 58206c6863f6b861a5e2fa6d3599e487294ded63
Author: Siddhesh Poyarekar <siddhesh@redhat.com>
Date:   Thu Jun 13 09:54:35 2013 +0530

    Improve precision of clock() function on Linux

    Resolves #12515.

    Use CLOCK_PROCESS_CPUTIME_ID instead of times to get better precision
    in the value returned by clock.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/12515] clock() should provide better precision

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=12515

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|                            |security-

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/12515] clock() should provide better precision

[vincent-srcware at vinc17 dot net]

https://sourceware.org/bugzilla/show_bug.cgi?id=12515

Vincent Lefèvre <vincent-srcware at vinc17 dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vincent-srcware at vinc17 dot net

--- Comment #15 from Vincent Lefèvre <vincent-srcware at vinc17 dot net> ---
I disagree with the reason of the change. This is all about precision vs
accuracy. But this is more a documentation issue. I've reported a new bug about
the documentation:

  https://sourceware.org/bugzilla/show_bug.cgi?id=17383

(this is against the manual, the IMHO, the code itself should be better
documented).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-26269-listarch-glibc-bugs=sources.redhat.com@sourceware.org Fri Sep 12 12:18:04 2014
Return-Path: <glibc-bugs-return-26269-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 21461 invoked by alias); 12 Sep 2014 12:18:04 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 21311 invoked by uid 48); 12 Sep 2014 12:18:00 -0000
From: "vincent-srcware at vinc17 dot net" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug manual/17383] clock() documentation should say something about the implementation and the accuracy
Date: Fri, 12 Sep 2014 12:18:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: manual
X-Bugzilla-Version: 2.20
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: vincent-srcware at vinc17 dot net
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-17383-131-iW88bAOTNj@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-17383-131@http.sourceware.org/bugzilla/>
References: <bug-17383-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-09/txt/msg00191.txt.bz2
Content-length: 485

https://sourceware.org/bugzilla/show_bug.cgi?id=17383

--- Comment #1 from Vincent Lefèvre <vincent-srcware at vinc17 dot net> ---
Let's note that with CLOCKS_PER_SEC = 1000000, clock() has a fixed precision of
1 ms. What have changed are:
* the precision of the underlying function;
* as a consequence, the accuracy of the clock() function. But it is still
unclear what it actually is.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-26270-listarch-glibc-bugs=sources.redhat.com@sourceware.org Fri Sep 12 12:19:14 2014
Return-Path: <glibc-bugs-return-26270-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 22088 invoked by alias); 12 Sep 2014 12:19:14 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 22055 invoked by uid 48); 12 Sep 2014 12:19:11 -0000
From: "vincent-srcware at vinc17 dot net" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug manual/17383] clock() documentation should say something about the implementation and the accuracy
Date: Fri, 12 Sep 2014 12:19:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: manual
X-Bugzilla-Version: 2.20
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: vincent-srcware at vinc17 dot net
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-17383-131-EKLJepQ0wY@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-17383-131@http.sourceware.org/bugzilla/>
References: <bug-17383-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-09/txt/msg00192.txt.bz2
Content-length: 397

https://sourceware.org/bugzilla/show_bug.cgi?id=17383

--- Comment #2 from Vincent Lefèvre <vincent-srcware at vinc17 dot net> ---
(In reply to Vincent Lefèvre from comment #1)
> Let's note that with CLOCKS_PER_SEC = 1000000, clock() has a fixed precision
> of 1 ms.

Sorry, I meant 1 µs.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-26271-listarch-glibc-bugs=sources.redhat.com@sourceware.org Fri Sep 12 13:49:26 2014
Return-Path: <glibc-bugs-return-26271-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 16703 invoked by alias); 12 Sep 2014 13:49:25 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 16662 invoked by uid 48); 12 Sep 2014 13:49:22 -0000
From: "jim.king at simplivity dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug libc/12926] getaddrinfo()/make_request() may spin forever
Date: Fri, 12 Sep 2014 13:49:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: libc
X-Bugzilla-Version: 2.15
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jim.king at simplivity dot com
X-Bugzilla-Status: REOPENED
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: drepper.fsp at gmail dot com
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: security-
X-Bugzilla-Changed-Fields: bug_status cc version resolution
Message-ID: <bug-12926-131-QaqVXpwjNu@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-12926-131@http.sourceware.org/bugzilla/>
References: <bug-12926-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-09/txt/msg00193.txt.bz2
Content-length: 1741

https://sourceware.org/bugzilla/show_bug.cgi?id\x12926

James E. King, III <jim.king at simplivity dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |jim.king at simplivity dot com
            Version|unspecified                 |2.15
         Resolution|INVALID                     |---

--- Comment #3 from James E. King, III <jim.king at simplivity dot com> ---
I recently discovered root cause of an issue I was investigating to the same
root cause described in Paul's original report below.  Regardless of whether
the application is behaving correctly, the documentation for recvmsg clearly
states:

--

RETURN VALUE
  These calls return the number of bytes received, or -1 if an error occurred.
  The return value will be 0 when the peer has performed an orderly shutdown.

--

It would make sense that once one received zero as a result, subsequent calls
would also return zero, and that is exactly what was reported - an infinite
loop.  A fix was provided that appears correct however the defect was closed as
invalid.  I'd like to request this be re-opened and the fix proposed be
implemented.

There are potentially more reasons than what was suggested in post number two
as to why zero could be returned.  There is evidence in other net posts that
changing the networking configuration of the system (administrative or
automatically) during the operation could cause this.

This code defect exists at least in eglibc-2.15 through eglibc-2.19.

--
You are receiving this mail because:
You are on the CC list for the bug.