Does this code cause undefined behaviour? Because the buffer is only 128 byte long but i tell snprintf() that it is longer. However, the resulting string is shorter than 128 byte.
#include <stdio.h> int main(void) { char buffer[128]; snprintf(buffer,294201,"%s","ABC"); puts(buffer); return 0; } C 2018 7.21.6.5 2 says:
The
snprintffunction is equivalent tofprintf, except that the output is written into an array (specified by arguments) rather than to a stream. Ifnis zero, nothing is written, andsmay be a null pointer. Otherwise, output characters beyond then-1st are discarded rather than being written to the array, and a null character is written at the end of the characters actually written into the array.
Note this does not say snprintf is passed an array of n or more characters. So snprintf is not given any license to assume it may write to s[n-1] unless the fprintf that it is equivalent to would write n characters (including the terminating null character).
Looking at this another way, suppose we define an array buffer of 294,201 characters, fill it with data, and call snprintf(buffer,294201,"%s","ABC");. Would we expect nothing beyond the first four characters to change? If some other byte in the buffer changed, then this snprintf call would not be “equivalent to fprintf, except that the output is written into an array…” I would deem it a violation of this specification if it changed anything further in the buffer.
snprintf() source looking for possible code doing something like buffer + 294201 to form a "do not write pass this pointer". Since that addition is possible UB, that would be a problem. But source code does not do that - so perhaps speaks to implementation's good quality. Accounting for a possible overvalued size_t n makes for an interesting coding restriction.
snprintf does not specify it is passed an array of size at least n or of any size except that needed to write the characters the specification says snprintf writes. So doing the address calculation in any way that has undefined behavior according to both the C standard and the implementation would not conform to the specification of the snprintf routine. (The implementation could do the calculation if it pleases and it guarantees no adverse effects.)
fprintf().fprintf()does not write past what is needs. I suppose the question is, may it access beyond, hmmm. I think 294201 being more than 128 is not UB, but we are on thin ice. Good luck.fprintf()does not write a'\0'character to the file,snprintf()does write one. Maybe an implementation writes'\0'at the end (so there is one in case the result is too long) and then writes the data.snprintfimplementation would write further into the buffer than past the terminating null character. Any writing beyond the null character would be completely useless and just waste CPU cycles. But you never know. But for me the code you show is broken, even if most likely nothing bad is going to happen..... Full spec covers more detail.snprintf()attempting to do abuffer + 294201addition that is invalid. I'm leaning toward UB now.