[tz] Minor (unimportant really) technical UB bug in strftime() ?

Paul Eggert eggert at cs.ucla.edu
Thu Nov 10 23:46:36 UTC 2022


On 11/10/22 02:17, Clive D.W. Feather wrote:
> Implementations or tools like lint or valgrind? Are there implementations
> that can't copy an arbitrary byte of memory to another location?

It depends on what one means by "implementation". There are combinations 
of compilers and runtimes that operate that way. Valgrind is one 
example, and as Yann reports Clang is another if you use certain options.

I don't know of any platform that cannot copy uninitialized bytes no 
matter what: valgrind is optional, and clang's -fsanitize option is 
optional, and you can run your program without these options. Still, I 
don't understand why the C committee required implementations to support 
copying from uninitialized memory. Such copying is not that useful in 
practice, and since it's quite useful to treat it to be an error, why 
force implementations to support it?

I'm curious about this partly because the C standard's wording in this 
area is (a) so obscure that I didn't know about it despite long 
experience reading the standard, and (b) so buggy that the committee had 
to change the wording again in C23, because the wording in C17 was so 
unclear that it was misinterpreted. (And this is a tricky business: the 
wording was changed multiple times in the drafting process for C23.) The 
C committee has evidently gone to some length to require support for the 
obscure and troublesome feature of copying uninitialized data, for 
reasons that escape me.


More information about the tz mailing list