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.