[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