Hide Forgot
Description of problem: Valgrind's memcheck tool reports memory errors from strftime if tm.tm_hour is uninitialised, even when no conversion specifier requires the tm_hour field. Version-Release number of selected component (if applicable): glibc-2.7-2 How reproducible: Always Steps to Reproduce: Compile the attached testcase and run it with valgrind Actual results: $ gcc strftime.c -g && valgrind ./a.out ==5166== Memcheck, a memory error detector. ==5166== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al. ==5166== Using LibVEX rev 1732, a library for dynamic binary translation. ==5166== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP. ==5166== Using valgrind-3.2.3, a dynamic binary instrumentation framework. ==5166== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al. ==5166== For more details, rerun with: -v ==5166== ==5166== Conditional jump or move depends on uninitialised value(s) ==5166== at 0x32F889213D: __strftime_internal (strftime_l.c:578) ==5166== by 0x4004DD: main (strftime.c:10) ==5166== ==5166== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 1) ==5166== malloc/free: in use at exit: 0 bytes in 0 blocks. ==5166== malloc/free: 8 allocs, 8 frees, 3,048 bytes allocated. ==5166== For counts of detected errors, rerun with: -v ==5166== All heap blocks were freed -- no leaks are possible. After initialising tm_hour the second strftime call gives no error. Expected results: No memcheck errors. Additional info: The reference is on line 578 of strftime_l.c - tm_hour is copied into hour12 and then that is used in a condition. hour12 doesn't actually affect the output unless tm_hour is used, but by then it's too late as valgrind has already complained.
Created attachment 290917 [details] testcase
Created attachment 290918 [details] patch to avoid referencing tm_hour too early something like this is needed to delay any dependency on tm_hour
glibc will not change just to shut up valgrind. There is no bug in this case.