This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

[Various] libc/1864: strtol does not return 0xFFFFFFFFFFFF00FF when fed "0xFFFFFFFFFFFF00FF"


We've received the appended bug report.  Can anybody clarify this,
please?

If I understand this correctly, the basic question is whether strtol
handles:
Numbers > 0x8000000000000000 as a negative number - or not.

Btw. this works with strtoul.  I've added this as a testcase to
tst-strtol and tst-strtoll.  Please tell me if the tests cases are
correct (in this case the report is wrong) - or wrong and we need to
fix strtol/strtoll.

Andreas

2000-08-21  Andreas Jaeger  <aj@suse.de>

	* stdlib/tst-strtol.c: Add test for 0xFFFFFFFFFFFF00FF (from PR
	libc/1864).
	* stdlib/tst-strtoll.c: Likewise.

============================================================
Index: stdlib/tst-strtol.c
--- stdlib/tst-strtol.c	2000/05/23 08:42:56	1.18
+++ stdlib/tst-strtol.c	2000/08/21 15:37:04
@@ -54,7 +54,7 @@
   {"yz!", 34 * 36 + 35, 36, '!', 0},
   {"-yz", -(34*36 + 35), 36, 0, 0},
   {"GhI4", ((16*20 + 17)*20 + 18)*20 + 4, 20, 0, 0},
-  
+
   /* extremes... */
 #if LONG_MAX == 0x7fffffff
   {"2147483647", 2147483647, 0, 0, 0},
@@ -73,6 +73,7 @@
   {"-9223372036854775808", -9223372036854775808, 0, 0, 0},
   {"-9223372036854775809", -9223372036854775808, 0, 0, ERANGE},
   {"0x112233445566778899z", 9223372036854775807, 16, 'z', ERANGE},
+  {"0xFFFFFFFFFFFF00FF" , 9223372036854775807, 0, 0, ERANGE},
 #endif
   {NULL, 0, 0, 0, 0},
 
============================================================
Index: stdlib/tst-strtoll.c
--- stdlib/tst-strtoll.c	2000/05/23 08:42:56	1.3
+++ stdlib/tst-strtoll.c	2000/08/21 15:37:04
@@ -68,6 +68,7 @@
   {"-9223372036854775808", -9223372036854775807ll - 1, 0, 0, 0},
   {"-9223372036854775809", -9223372036854775807ll - 1, 0, 0, ERANGE},
   {"0x112233445566778899z", 9223372036854775807ll, 16, 'z', ERANGE},
+  {"0xFFFFFFFFFFFF00FF" , 9223372036854775807ll, 0, 0, ERANGE},
   {NULL, 0, 0, 0, 0},
 
   /* Then unsigned.  */


Subject: Topics

Topics:
   Re: libc/1864: strtol does not return 0xFFFFFFFFFFFF00FF when fed "0xFFFFFFFFFFFF00FF" 
   libc/1864: strtol does not return 0xFFFFFFFFFFFF00FF when fed "0xFFFFFFFFFFFF00FF"




Thank you for you reply.

> How would you expect it to work?  strtol returns LONG_MAX in case of
> an overflow - and an overflow happens in this case.

> Sorry, I don't really understand what you're complaining about.

What I am asking about is that if I feed strtol the string
"0xFFFFFFFFFFFF00FF" which is a valid hex number within the
range 0x8000000000000000 to 0x7FFFFFFFFFFFFFFF it comes
back as number out of range.

I would expect it to return 0xFFFFFFFFFFFF00FF (-65281) it
does not.

If you are saying that strtol can only be fed +ve hex strings
then that is fine, inconsistant as it can be fed -ve decimal
numbers, but fine. In that case the documentation is faulty.

Thanks again.

--------
Eamon.
Work: eamon@sonyoxford.co.uk
Home: eamon@eamons.com
www: http://www.eamons.com

"There are two ways of disliking poetry; one way is to dislike it, the
other is to read Pope."
		-- Oscar Wilde

#include <standard_disclaimer.h>
Extra Disclaimer: Any resemblance between the above views and those
of my employer, my terminal, or the view out my window are purely
coincidental.  Any resemblance between the above and my own views is
non-deterministic.  The question of the existence of views in the
absence of anyone to hold them is left as an exercise for the reader.
The question of the existence of the reader is left as an exercise
for the second god coefficient.  (A discussion of non-orthogonal,
non-integral polytheism is beyond the scope of this article.)

!!!!!That's all folks!!!!!






>Number:         1864
>Category:       libc
>Synopsis:       strtol does not return 0xFFFFFFFFFFFF00FF when fed "0xFFFFFFFFFFFF00FF"
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    libc-gnats
>State:          open
>Class:          sw-bug
>Submitter-Id:   unknown
>Arrival-Date:   Mon Aug 21 10:20:02 EDT 2000
>Last-Modified:
>Originator:     eamon@sonyoxford.co.uk
>Organization:
net
>Release:        2.1.1
>Environment:
Running on an Dec Alpha OSF4.0
>Description:
If you feed strtol the string "0xFFFFFFFFFFFF00FF" it returns 
0x7FFFFFFFFFFFFFFF [Result too large].

Looking at the code it is good until it reaches ...

Line 414

  /* Check for a value that is within the range of
     `unsigned LONG int', but outside the range of `LONG int'.  */
  if (overflow == 0
      && i > (negative
          ? -((unsigned LONG int) (STRTOL_LONG_MIN + 1)) + 1
          : (unsigned LONG int) STRTOL_LONG_MAX))
        {
    overflow = 1;
        }

It then compares i (unsigned) with 0x8000000000000000 and fails.

This is not how I would expect this to work.

Thanks.

I can't find a report like this in the data base and I apologise
for sending the bug like this rather than using glibcbug, but
the library is not installed on these machines. I found the bug
in the standard DEC compiler and then copied the source for
strtol to a standalone directory and steped through it to the
above point. I think that this is a bug but am willing to be
proved wrong.

Thanks again.
>How-To-Repeat:
Feed it...
#include    <stdio.h>
#include    <errno.h>

main()
{
char *t="0xFFFFFFFFFFFF00FF";
errno = 0;

printf("0x%0lX ",strtol(t,0,0));
printf("[%s]\n",strerror(errno));
}
%0
>Fix:
>Audit-Trail:
>Unformatted:





-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj
Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]