Bug 427673

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.