From nobody@FreeBSD.org  Mon Jun 22 20:16:51 2009
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 3BE121065672
	for <freebsd-gnats-submit@FreeBSD.org>; Mon, 22 Jun 2009 20:16:51 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21])
	by mx1.freebsd.org (Postfix) with ESMTP id 29E848FC14
	for <freebsd-gnats-submit@FreeBSD.org>; Mon, 22 Jun 2009 20:16:51 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.14.3/8.14.3) with ESMTP id n5MKGog9028740
	for <freebsd-gnats-submit@FreeBSD.org>; Mon, 22 Jun 2009 20:16:50 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.14.3/8.14.3/Submit) id n5MKGoDj028739;
	Mon, 22 Jun 2009 20:16:50 GMT
	(envelope-from nobody)
Message-Id: <200906222016.n5MKGoDj028739@www.freebsd.org>
Date: Mon, 22 Jun 2009 20:16:50 GMT
From: Yuri <yuri@tsoft.com>
To: freebsd-gnats-submit@FreeBSD.org
Subject: 'strtol' doesn't reset errno to 0 when converting MAX_INT=2147483647
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         135932
>Category:       kern
>Synopsis:       [libc] strtol(3) doesn't reset errno to 0 when converting MAX_INT=2147483647
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Jun 22 20:20:01 UTC 2009
>Closed-Date:    Sat Jul 04 20:17:29 UTC 2009
>Last-Modified:  Sat Jul 04 20:17:29 UTC 2009
>Originator:     Yuri
>Release:        72-STABLE
>Organization:
n/a
>Environment:
>Description:
When strtol is supplied string 2147483647 it's impossible to distinguish between overflow and non-overflow situation since return value is the same one that flags overflow (MAX_INT) and strtol doesn't clear errno in this case.

strtol should set errno=0 in this case to avoid ambiguity.

errno can accidentally be set to 34 (ERANGE) before the call and this will affect the conversion decision in this case. And requiring all programs to reset errno before the call isn't right too since the proposed here simple fix fixes this ambiguity for every program.

-- testcase --
#include <stdlib.h>
#include <limits.h>
#include <errno.h>
#include <stdio.h>

main() {
  const char *nptr = "2147483647";
  char *endptr;
  errno=34; // ERANGE
  int res = ::strtol(nptr, &endptr, 10);
  printf("res=%i errno=%i\n", res, errno);
}

--- output --- 
res=2147483647 errno=34

>How-To-Repeat:

>Fix:


>Release-Note:
>Audit-Trail:

From: Bruce Evans <brde@optusnet.com.au>
To: Yuri <yuri@tsoft.com>
Cc: freebsd-gnats-submit@FreeBSD.org, freebsd-bugs@FreeBSD.org
Subject: Re: misc/135932: 'strtol' doesn't reset errno to 0 when converting
 MAX_INT=2147483647
Date: Tue, 23 Jun 2009 12:02:12 +1000 (EST)

 On Mon, 22 Jun 2009, Yuri wrote:
 
 >> Description:
 > When strtol is supplied string 2147483647 it's impossible to distinguish between overflow and non-overflow situation since return value is the same one that flags overflow (MAX_INT) and strtol doesn't clear errno in this case.
 
 No, this is easy to distinguish: set errno to 0 (or just to some value
 different from ERANGE) before calling strtol(), and check errno after
 calling strtol().  The check can be omitted unless strtol() actually
 returns INT_MAX.  The setting before the call can only be omitted it
 this error can't happen or if the caller doesn't check for it.  Most
 uses of the strtol() family get this wrong by not even checking :-(.
 
 > strtol should set errno=0 in this case to avoid ambiguity.
 
 No, strtol() must not set errno to 0.  The C standard doesn't permit any
 library function to set errno to 0.
 
 Bruce
State-Changed-From-To: open->closed 
State-Changed-By: jilles 
State-Changed-When: Sat Jul 4 20:17:28 UTC 2009 
State-Changed-Why:  
Not a bug, and the suggested change is against standards. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=135932 
>Unformatted:
