4 ms·

no, because the size argument is only an upper bound on how many bytes can be written into the destination. snprintf (huge_buf, huge_buffer_size, "%d", 1);

no, because the size argument is only an upper bound on how many bytes can be written into the destination. snprintf (huge_buf, huge_buffer_size, "%d", 1); will write two bytes into huge_buf, regardless of huge_buffer_size (assuming it is 2 or larger).

saagarjha 4y ago
It’s in the other direction, snprintf(small_buf, small_size, “%s”, huge_string) will need to iterate the whole string.
- PaulDavisThe1st 4y ago
  why? snprintf() will just write as many bytes from huge_string as necessary, up to the smaller of small_size and strlen (huge_string). what makes you believe it will iterate the whole of huge_string?
  - saagarjha 4y ago
    Quoth the standard: > The snprintf function returns the number of characters that would have been written had n been sufficiently large, not counting the terminating null character, or a negative value if an encoding error occurred. In essence it needs to return strlen of huge_string even though very little of it was actually written.
    - PaulDavisThe1st 4y ago
      Well that's pretty fucked up. I note that the GNU C library docs say this: > Attention: In versions of the GNU C Library prior to 2.1 the return value is the number of characters stored, not including the terminating null; unless there was not enough space in s to store the result in which case -1 is returned. This was changed in order to comply with the ISO C99 standard. ISO C99 needs a kick in the head. Yes, there is a use case for this return value (buffer wasn't large enough, reallocate and try it again). But wow, own goal team! Thanks for this. I had no idea that C99 had defined this so stupidly. I do see that in 2004, the linux kernel added replacements (scnprintf() which behave as the pre-C99 versions of snprintf generally did). There's a good discussion of this here: https://lwn.net/Articles/69419/ https://lwn.net/Articles/69419/

saagarjha 4y ago

It’s in the other direction, snprintf(small_buf, small_size, “%s”, huge_string) will need to iterate the whole string.

PaulDavisThe1st 4y ago
why? snprintf() will just write as many bytes from huge_string as necessary, up to the smaller of small_size and strlen (huge_string). what makes you believe it will iterate the whole of huge_string?
- saagarjha 4y ago
  Quoth the standard: > The snprintf function returns the number of characters that would have been written had n been sufficiently large, not counting the terminating null character, or a negative value if an encoding error occurred. In essence it needs to return strlen of huge_string even though very little of it was actually written.
  - PaulDavisThe1st 4y ago
    Well that's pretty fucked up. I note that the GNU C library docs say this: > Attention: In versions of the GNU C Library prior to 2.1 the return value is the number of characters stored, not including the terminating null; unless there was not enough space in s to store the result in which case -1 is returned. This was changed in order to comply with the ISO C99 standard. ISO C99 needs a kick in the head. Yes, there is a use case for this return value (buffer wasn't large enough, reallocate and try it again). But wow, own goal team! Thanks for this. I had no idea that C99 had defined this so stupidly. I do see that in 2004, the linux kernel added replacements (scnprintf() which behave as the pre-C99 versions of snprintf generally did). There's a good discussion of this here: https://lwn.net/Articles/69419/ https://lwn.net/Articles/69419/