| Summary: | Problems with sscanf parsing certain hex-floats | ||
|---|---|---|---|
| Product: | glibc | Reporter: | Moritz K. <BM-2cUWXLL9JqDWpsk8EivFHCgbsbXFtsxQrk> |
| Component: | stdio | Assignee: | Not yet assigned to anyone <unassigned> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | enhancement | CC: | fweimer |
| Priority: | P2 | Flags: | fweimer:
security-
|
| Version: | 2.26 | ||
| Target Milestone: | --- | ||
| Host: | Target: | ||
| Build: | Last reconfirmed: | ||
| Attachments: | example code, visualizing the behavior from above | ||
Created attachment 10712 [details] 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!