On 2017-05-22 17:10:08 -0400, shwares...@aol.com wrote: > The expected behavior is nothing gets written, since the size_t n > argument is 0. Whether *(&n) gets written to or not is ambiguous. > The implied behavior is that since it is only checking what the > buffer length should be, by the paragraph at line 31022, any %n is > ignored since no output is occurring for this be valid.
I would agree with you, and a few weeks ago, I wrote a bug report against GNU libc because it fills the argument associated with %n when there is no overflow: https://sourceware.org/bugzilla/show_bug.cgi?id=21360 where I gave the example: #include <stdio.h> int main(void) { int r, n = -1; r = snprintf (NULL, 0, "foo%n", &n); printf ("%d %d\n", r, n); return 0; } I expected 3 0, but glibc gives 3 3. But it was decided that this was a defect in the C standard, and the bug was invalid. > The overflow happens in strtoi of the %s part, strtoi? The C standard just says for the field width: "The field width takes the form of an asterisk * (described later) or a nonnegative decimal integer." It doesn't say that the nonnegative decimal integer has some given type, so that I assume that it is unbounded a priori. > so I would expect it to abort with EOVERFLOW when that's processed > and not even get to the %n, as an illegal format string. The > standard leaves ambiguous whether INT_MAX is assumed in this case, > however, so an implementation that does process the %n anyways might > store INT_MAX. It should be explicit in that paragraph, imo, %n > isn't processed and the value pointed to left unmodified. If it is decided that an overflow on the return value (which is of type int) may prevent the %n arguments from being written, then the field width may be read in an int (as if it is larger than INT_MAX, then there will necessarily be an overflow on the return value). But if it is decided that the overflow should affect only the return value, then the field width would typically be read in an intmax_t, in case one would have a "%jn" at some point. -- Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
