[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