Conversation

Notices

1. Embed this notice
   Erin 💽✨ (erincandescent@akko.erincandescent.net)'s status on Wednesday, 16-Oct-2024 04:10:02 JST Erin 💽✨

   So I have set of interesting C corner cases…

   Consult 7.24.1.7 of WG14 N3220, concering “The strtol, strtoll, strtoul, and strtoull functions” and then look at the following:

   // C23 // In all of the following assume errno is initially 0 // Unambiguous r = strtoul("0", &endp, 0) r = strtoul("0", &endp, 2) r = strtoul("0", &endp, 16) // -> strcmp(endp, "") == 0, r = 0, errno = 0; r = strtoul("0b0", &endp, 0) r = strtoul("0x0", &endp, 0) r = strtoul("0b0", &endp, 2) r = strtoul("0x0", &endp, 16) // -> strcmp(endp, "") == 0, r = 0, errno = 0; // The following are ambiguous, however. // What is the correct output for each of these? strtoul("0b", &endp, 0) strtoul("0b", &endp, 2) // -> strcmp(endp, "b") == 0, r = 0, errno = 0;, or // -> errno = ERANGE strtoul("0x", &endp, 0) strtoul("0x", &endp, 16) // -> strcmp(endp, "x") == 0, r = 0, errno = 0;, or // -> errno = ERANGE

   Note: in versions of C prior to C23, the following are unambiguous (the language permitting the 0b prefix was added in C23). Depending upon interpretation, in C23 strtoul may reject inputs that were considered acceptible in in previous versions of the standard

   strtoul("0b", &endp, 0) strtoul("0b", &endp, 2) // -> strcmp(endp, "b") == 0, r = 0, errno = 0;
   • Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     Amber (puppygirlhornypost2@transfem.social)'s status on Wednesday, 16-Oct-2024 04:10:59 JST Amber

     in reply to

     @erincandescent@akko.erincandescent.net thanks i hate it

     Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     Erin 💽✨ (erincandescent@akko.erincandescent.net)'s status on Wednesday, 16-Oct-2024 04:15:48 JST Erin 💽✨

     in reply to

     Anyway I think this interpretation means a C standard library implementation needs different implementations of scanf and strtoul to be conformant to both C23 and C17 and earlier.

     My displeasure is imeasurable and my day is ruined.

     :drgn_dizzy:

     Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     Erin 💽✨ (erincandescent@akko.erincandescent.net)'s status on Wednesday, 16-Oct-2024 04:15:49 JST Erin 💽✨

     in reply to

     Previous discussion on the glibc issue tracker and with the committee seems to indicate that for this case (2)/(3) is the correct result. I find this outcome emotionally upsetting (but then, that describes lots of the specifics of scanf…) but it is at least internally consistent.

     glibc for the first case will currently produce r=1, n=2, o=0 which is just nonsense, but at least its acknowledged as a (very old!) bug

   • Embed this notice
     Erin 💽✨ (erincandescent@akko.erincandescent.net)'s status on Wednesday, 16-Oct-2024 04:15:51 JST Erin 💽✨

     in reply to

     Relatedly: The %x conversion specifier in fscanf is defined in terms of strtoul. fscanf is only allowed one character of lookahead (see §7.23.6.2 footnote 332, “fscanf pushes back at most one input character onto the input stream. Therefore, some sequences that are acceptable to strtod, strtol, etc., are unacceptable to fscanf.”). sscanf and scanf are both defined in terms of fscanf.

     Consider this sequence of code:

     unsigned int o; int n; int r = sscanf("0xZZ", "%x%n", &o, &n);

     Is the result

     1. r=1 (one conversion was possible), n=1 (one byte of input consumed), o=0 (we consumed the single zero digit)
     2. r=0 (no conversion was possible) because 0x is a valid prefix of a conversion specifier but is not a valid input to strtoul (see previous post)

     Now consider

     int r = sscanf("0xAA", "%x%n", &o, &n);

     We have a third potential option here: r=1, n=4, o=0xAA

     however per the above footnote we must pick that our result is

     • (1) in both cases
     • (2) in both cases
     • (2) in the first case, (3) in the second

     In particular combo (1) and (3) is impossible because it would require us to peak ahead two characters (xZ/xA) in order to know which of the two cases we are in

     I think (1) in both cases is the only reasonable result and the standard should probably call out explicitly that the 0b/0x prefixes are not permitted for the input to the %b/%x conversion specifiers respectively.