xcancel com/raysan5/status/2049451452997742657>commits babbies first UB>cries on twitter how the stdlib isn't being "consistent"And a retard like that created one of the most well-liked C graphics libraries? Does this entire industry consist only of retards? Sorry for the twitter screenshot thread, but HOW?? And the comments are full of people excusing this as if it weren't an inexcusable error for anyone with a little C experience.
>>108759538Because UB is inherently such a niggerlicious concept that anyone should be disgusted by it, no matter how much experience he or she has.
>>108759616nooo you can't decide in advance that compilers have to be well-behaved, you'll break the opportunity for convoluted optimization passes that rely on unfounded assumptions!!1
>>108759616Well, what's the alternative?>>108759629There's no crazy optimisation going on in the op pic, it's the most basic case of reading beyond a memory buffer.
>>108759538snprintfhttps://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170Return valueThe number of characters that would have been written to the buffer if count was ignored. The count doesn't include the terminating NULL character.man 3 snprintfRETURN VALUE Upon successful return, these functions return the number of bytes printed (excluding the null byte used to end output to strings).There's no world in which you would need the print function to return the length of the input string instead of the amount written.But there's also a 100% so much software expecting this behavior and someone recompiling this shit wouldn't know 100%.Like bro just strlen(inputString);
>>108759538Casey has a more nuanced take: https://www.youtube.com/watch?v=zRLnZhhJqpg explaining specifically why even though it's undefined behavior why it behaves like it does. He will do a follow up post explaining why the 64-bit version works as it does.
>>108759685>There's no world in which you would need the print function to return the length of the input string instead of the amount written.Sure there is. Its to know if you need to realloc to fit the entire string (or to know if it was truncated).
>>108759701and the example for "man snprintf" even shows it. They first call vsnprintf with a null pointer to get the size and then malloc that size and use it in vsnprintf again
>>108759685firstly, your bloody fault if you use a function without reading its documentation.secondly, it's not the input string length, it's the expanded format string, a very different thing the length of which you cannot reliably predict.this function is really useful(although unless you have a good estimate of your percentiles, you should probably just be using asprintf instead)
>>108759688uh yeah, that's a basic walk-through of the result and also how I initially came across the twitter post
>>108759685also, the manpage for snprintf states>The functions snprintf() and vsnprintf() do not write more than size bytes (including the terminating null byte ('\0')). If the output was truncated due to this limit, then the return value is the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated. (See also below under CAVEATS.)
>>108759646NTA but that doesn't change the fact that UB exists specifically to facilitate optimizations, even if most of them aren't even particularly convoluted.
>>108759538I would not call it UB. It's more like the programmer being a retard by trying to print a non null terminated string.
>>108759538Guy is definitely dumb. He passed a non-null terminated string to sprintf.
>>108761262UB was never originally intended for that. GCC and Clang decided to maliciously interpret the standard to make micro-benchmarks a bit faster. MSVC does not do that, you can trust MSVC not to break you code depending on its mood.
>>108759538It's because the smallest possible malloc chunk is two words and calloc zeros the whole thing including padding.
>>108761407(Technically, it's 2 * sizeof(void *), but unless you time travel back 30 years that'll be the same as two words.)
It's platform defined, sir. Also it depends on where the allocation is, for example if reverse the allocation order on 32bit system and you have all the bytes set to zero in that specific memory area you will get the same result.
>>108761490>if reverse the allocation order on 32bit systemEven assuming that it's a clean arena and both blocks get put right next to each other you'd still get different results. There's a chunk header that gets put before each chunk and the first byte of it on little endian machines is the flag byte (and thus pretty much guaranteed to be nonzero).
>>108761248I dont think the vast majority of people know that calloc allocates more memory than you request (and sets it to 0), especially on 64-bit systems because of SIMD alignment.
>>108759538>experienced C coder>makes basic memory mistakes>but you don't need Rust!>you only need better coders!And that's how we got the world where Linux get pwned on the regular by 700-character Python scripts...
