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):
Steps to Reproduce:
Compile the attached testcase and run it with valgrind
$ 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== 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== 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.
No memcheck errors.
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
Created attachment 290917 [details]
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.