Anonymous | Login | 2024-03-29 11:25 UTC |
Main | My View | View Issues | Change Log | Docs |
Viewing Issue Simple Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||
ID | Category | Severity | Type | Date Submitted | Last Update | ||
0001181 | [1003.1(2016/18)/Issue7+TC2] System Interfaces | Editorial | Clarification Requested | 2017-12-29 13:52 | 2019-02-18 17:02 | ||
Reporter | steffen | View Status | public | ||||
Assigned To | |||||||
Priority | normal | Resolution | Rejected | ||||
Status | Closed | ||||||
Name | steffen | ||||||
Organization | |||||||
User Reference | |||||||
Section | sscanf | ||||||
Page Number | 951 | ||||||
Line Number | 32310 ff. | ||||||
Interp Status | --- | ||||||
Final Accepted Text | |||||||
Summary | 0001181: *scanf(): %i format: seems to use unsigned in the wild for known base(s) | ||||||
Description |
Very deep in what i got used to is that the high bit represents the signedness state of a number, and i tend to write hexadecimal numbers this way. That is to say that i always had problems with how that standard strtol() series fails to parse hexadecimal 0x80000000 (with 32-bit long), not to talk about 0xFFFFFFFF (ditto), which simply is -1: i would never write -0x1 to get that in hexadecimal. But that is how the standard is written. Interestingly it seems that some libraries support that kind of view for the %i format of the *scanf() series, even though it is the standard which says that %i shall act like strtol() with a base of 0. The behaviour does not seem to be consistent though (note i cannot test Solaris because i have messed my OpenCSW account, grmpf!): E.g., the program below on a 64-bit musl Linux: ?0[steffen@essex tmp]$ tcc -run t.c 0xFFFFFFFFFFFFFF7F: 0xFFFFFFFFFFFFFF7F ?0[steffen@essex tmp]$ tcc -run t.c 1 0xFFFFFFFFFFFFFF7F: 0x7FFFFFFFFFFFFFFF (34: Result not representable) On a 32-bit OpenBSD: ?0[steffen@obsd tmp]$ ./zt 0xFFFFFFFFFFFFFF7F: 0x7FFFFFFFFFFFFFFF ?0[steffen@obsd tmp]$ ./zt 1 0xFFFFFFFFFFFFFF7F: 0x7FFFFFFFFFFFFFFF (34: Result too large) But, adjusted to work with long/strtol() instead we get where i want to be! ?0[steffen@obsd tmp]$ ./zt 1 0xFFFFFF7F: 0x7FFFFFFF (34: Result too large) ?0[steffen@obsd tmp]$ ./zt 0xFFFFFF7F: 0xFFFFFF7F As can be seen unsigned parse mode seems to become used for %i on multiple systems if the number uses a power-of-two base with known prefix. The program is: #include <errno.h> #include <stdlib.h> #include <stdio.h> #include <string.h> int main(int argc, char **argv){ char buf[32]; int e; long long l; l = -129; snprintf(buf, sizeof buf, "0x%llX", l); printf("%s: ", buf); if(argc > 1){ errno = 0; l = strtoll(buf, NULL, 0); e = errno; printf("0x%llX (%d: %s)\n", l, e, strerror(e)); }else{ sscanf(buf, "%lli", &l); printf("0x%llX\n", l); } return 0; } |
||||||
Desired Action | Allow automatic treatment of power-of-two bases with known standardized prefix as unsigned for *scanf() %i and strtol*(). | ||||||
Tags | No tags attached. | ||||||
Attached Files | |||||||
|
Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group |