Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0004210OCamlOCaml generalpublic2007-02-19 11:562013-09-03 13:33
Reporteroandrieu 
Assigned Toxleroy 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version3.10+dev 
Target VersionFixed in Version3.12.0+dev 
Summary0004210: little bug in int_of_string
Descriptionint_of_string "max_int + 1" does not raise an exception as it should.

# max_int ;;
- : int = 1073741823
# int_of_string "1073741824" ;;
- : int = -1073741824

in byterun/ints.c we have this comment:
/* Signed representation expected, allow -2^(nbits-1) to 2^(nbits - 1) */
the upper bound should be "2^(nbits - 1) - 1"
TagsNo tags attached.
Attached Filesdiff file icon max_int.diff [^] (6,461 bytes) 2009-06-26 20:51 [Show Content]

- Relationships
has duplicate 0004245closedxleroy Integer conversions do not detect overflow in corner cases 
has duplicate 0004876closedxclerc error in string to integers conversions 
related to 0003302closed Int64.of_string does not detect overflow from positive to negative ints 
related to 0003582acknowledged (1073741824 = -1073741824) is true ! 

-  Notes
(0003917)
oandrieu (reporter)
2007-02-19 12:16

This is suspicious too :

# int_of_string "0x4000_0000" ;;
- : int = -1073741824
# int_of_string "-0x4000_0000" ;;
- : int = -1073741824
(0003921)
xleroy (administrator)
2007-02-21 14:38

This is a known issue: when lexing source files, the (valid) integer literal
-1073741824 is read as "token -", then "integer (int_of_string "1073741824")),
and converted to -1073741824 later during parsing. It is therefore necessary that int_of_string "1073741824" does not fail. A cleaner approach would be to avoid int_of_string during lexing and use a specific string->int conversion function, but that's more work...

Concerning int_of_string "0x4000_0000", we adopt the convention that hexadecimal, octal and binary literals can be written either as unsigned (range 0..0x7FFF_FFFF) or signed (range -0x4000_0000..0x3FFF_FFFF). The same convention is used by Java for instance.
(0005004)
xleroy (administrator)
2009-06-23 18:18

I'm reopening this PR following discussions with Consortium members. It appears possible to fix int_of_string (so that it fails if given "max_int + 1") without breaking the lexer/parser. To be done for 3.12.
(0005007)
shinwell (developer)
2009-06-26 20:51

Here's one I prepared earlier :)

This patch fixes the system so that int_of_string and friends do not permit the relevant largest positive integer, plus one, to be converted. It does not affect lexing and parsing in any way.

This has only been tested with 3.11.0 64-bit so far, using an automatic test generator. We can do some further testing internally if the patch is likely to be of use.
(0005008)
shinwell (developer)
2009-06-26 20:54

I should add that the patch I've just uploaded only affects conversions in base 10. As far as I can work out, conversions in other bases are to be treated as if they are unsigned conversions (which makes sense, since you might want to directly set the sign bit in a hex representation).
(0005024)
xleroy (administrator)
2009-07-15 16:55

Tentative fix in CVS head. String -> integer conversion functions
(int_of_string, Int32.of_string, etc) now have tight bounds.

However, the lexer still accepts the literal representing
"max_int + 1", as before, and converts it to min_int, as before.

The fix should be functionally equivalent to Mark's patch, except that
we don't add new C functions; instead, we're using the folklore trick
of converting an integer literal s via -(int_of_string "-" ^ s).

- Issue History
Date Modified Username Field Change
2007-02-19 11:56 oandrieu New Issue
2007-02-19 12:16 oandrieu Note Added: 0003917
2007-02-21 14:38 xleroy Note Added: 0003921
2007-02-21 14:38 xleroy Status new => closed
2007-02-21 14:38 xleroy Resolution open => won't fix
2007-04-03 18:00 doligez Relationship added has duplicate 0004245
2009-06-23 18:18 xleroy Note Added: 0005004
2009-06-23 18:18 xleroy Assigned To => xleroy
2009-06-23 18:18 xleroy Resolution won't fix => open
2009-06-23 18:18 xleroy Status closed => assigned
2009-06-26 20:51 shinwell Note Added: 0005007
2009-06-26 20:51 shinwell File Added: max_int.diff
2009-06-26 20:54 shinwell Note Added: 0005008
2009-07-15 16:55 xleroy Note Added: 0005024
2009-07-15 16:55 xleroy Status assigned => resolved
2009-07-15 16:55 xleroy Resolution open => fixed
2009-07-15 16:55 xleroy Fixed in Version => 3.12.0+dev
2009-08-28 11:28 xleroy Relationship added related to 0003302
2009-09-24 14:35 xclerc Relationship added has duplicate 0004876
2011-05-29 12:14 xleroy Status resolved => closed
2013-09-03 13:33 doligez Relationship added related to 0003582


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker