[tz] Minor (unimportant really) technical UB bug in strftime() ?
Paul Eggert
eggert at cs.ucla.edu
Thu Nov 10 00:28:04 UTC 2022
On 11/9/22 11:25, Tom Lane wrote:
> So in the case in strftime(), Valgrind would only
> complain if mktime() actually tried to use any fields that had not
> been initialized by the caller of strftime(). Which is just what
> one would want.
True, and good point. And I understand why Valgrind wants to delay
checking here: it wants to avoid false alarms in some programs.
Unfortunately Valgrind's delay in reporting is problematic, because
Valgrind sometimes neglects to report behavior that the C standard says
is undefined. For example:
$ cat t.c
int main (void) { int a, b=a; return b; }
$ gcc t.c
$ valgrind ./a.out
[no error is reported]
Conversely, as my previous email showed, Valgrind sometimes reports
behavior that I think is a program failure that should be fixed, but the
C standard says is well-defined behavior. Although Valgrind was pickier
in that email than the C standard really allows, I wish Valgrind were a
bit pickier still and reported each use of an uninitialized variable
when it happens and not optionally later (by then, it may be difficult
to debug), and I'd like tzcode to work with such a Valgrind-like system.
More information about the tz
mailing list