-
-
Notifications
You must be signed in to change notification settings - Fork 6.7k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Enhance get_number() parsing (also eliminate Valgrind induced errors)
- Loading branch information
Trevor Welsby
committed
Jan 18, 2016
1 parent
b40408a
commit 09a4751
Showing
3 changed files
with
194 additions
and
104 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
09a4751
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The updated commit fixes the documentation/aesthetic issues identified as well as introducing a new parse method that is more efficient in that it only requires one parse for integers and does not require separating the floating point number with
modf
.The new method first parses using
strtoll()
/strtoull()
(looking for the minus sign to decide which) and then uses two tests to decide if further parsing is required:endptr
set bystrtoll()
/strtoull()
is equal tom_cursor
then the number parsed represents the entire number and there is no decimal point or exponent that wasn't parsed.If both of these conditions are not met then the number is parsed using
strtod()
. An attempt is made to cast it back in an integer form (using the method in the original code) to cover the case of numbers like 1.2e3 that are floating point numbers that can be accurately represented as integers. Finally a check is done for unexpected trailing characters so that an error may be thrown.The new parse method means that inputs such as "0." will no longer throw the exception "0 is not a number" but instead throw "unexpected '.'; expected end of input". This was an unexpected side effect of parsing using
strtoull()
/strtoll()
instead ofstrtod()
(which captures the "."), so the unit test has had to change. This is actually a good thing as the previous message, while convenient from a coding point of view, was misleading and, in the literal sense, nonsensical.The AppVeyor failure is the same as for the current upstream commit i.e. no new problems. It looks like a Catch problem and there are indications that this may be a known problem for which there is a fix in the development branch. As soon as I can get a VS build of the unit test I will give it a go (my current local repo is set up for Ubuntu only).