You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
where the year is zero, and not 2019 as expected. The reason is that sscanf attempts to read 20190523123456 as a whole integer, and then divide it with 1010 to obtain 2019, which obviously fails. Of course, 64-bit machines fail similarly on longer numerical strings.
The idea for a fix is to have a variant of _parse_integer() called _parse_integer_end(), with the ability to stop consuming digits. The functions
simple_{strtol,strtoll,strtoul,strtoull}()
now have the corresponding
sscanf_{strtol,strtoll,strtoul,strtoull}()
taking a field width into account. Perhaps such a fix could be a starting-point to clean-up the integer parsers? Also, it seems to be a good idea to make a test suite for sscanf.
The text was updated successfully, but these errors were encountered:
Fix 5380975 where
sscanf
overflows integers with simple strings such as dates. As an example, considerOn a 32-bit machine this prints
where the year is zero, and not 2019 as expected. The reason is that
sscanf
attempts to read 20190523123456 as a whole integer, and then divide it with 1010 to obtain 2019, which obviously fails. Of course, 64-bit machines fail similarly on longer numerical strings.The idea for a fix is to have a variant of
_parse_integer()
called_parse_integer_end()
, with the ability to stop consuming digits. The functionsnow have the corresponding
taking a field width into account. Perhaps such a fix could be a starting-point to clean-up the integer parsers? Also, it seems to be a good idea to make a test suite for
sscanf
.The text was updated successfully, but these errors were encountered: