This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug stdio/22672] New: Problems with sscanf parsing certain hex-floats
- From: "BM-2cUWXLL9JqDWpsk8EivFHCgbsbXFtsxQrk at bitmessage dot ch" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Thu, 04 Jan 2018 10:27:41 +0000
- Subject: [Bug stdio/22672] New: Problems with sscanf parsing certain hex-floats
- Auto-submitted: auto-generated
https://sourceware.org/bugzilla/show_bug.cgi?id=22672
Bug ID: 22672
Summary: Problems with sscanf parsing certain hex-floats
Product: glibc
Version: 2.26
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: stdio
Assignee: unassigned at sourceware dot org
Reporter: BM-2cUWXLL9JqDWpsk8EivFHCgbsbXFtsxQrk at bitmessage dot ch
Target Milestone: ---
Created attachment 10712
--> https://sourceware.org/bugzilla/attachment.cgi?id=10712&action=edit
example code, visualizing the behavior from above
Assume `d` as a normal double variable.
Executing
`sscanf ( "0x", "%lf", &d )`
returns `0` and `d` isn't modified, 'cause the string can't be parsed.
I think that 0x indicates in correspondence with `%lf`, that there seem to be a
maybe slightly incomplete hex-float.
But wouldn't it be a better behavior if this statement is correctly parsed into
the double `d` with the value `0`, 'cause ignoring the `x` and correctly
parsing `0` as well as assuming that `0x` originally means `0x0` is a much more
thought-out behavior than just saying "sry, but this can't be parsed, so it's
better doing nothing"?
Even though `sscanf ( "0x", "%i", &i )` returns successfully `1` and the
integer value `i` is going to have the value `0`. Furthermore e.g. BSD'
versions of GCC on MacOS correctly parses the 0x-lf case...
I'm using a x86_64-pc-linux-gnu 4.14.9-Linux to compile the code using
GCC-7.2.1 without any significant options (no compiler warnings present).
Thanks!
--
You are receiving this mail because:
You are on the CC list for the bug.