On 07/23/2015 07:50 AM, Kees Dekker wrote:
1.Why do you not always initialize the variables that are now passed to the INITIALIZE macro (see date.c/localtime.c/zic.c/private.h)? It has (almost) no impact on performance and prevents strict compilers to complain about (potentially) non-initialized variables.
Thanks for the careful reading of the code. Although INITIALIZE does improve performance very slightly, it is not primarily about performance. Mainly, it documents initialization that exists only to pacify compilers like GCC that would otherwise complain. If the code always initialized variables even when not needed, the code would become more confusing to human readers, as we'd have to puzzle out why the initialization is present even though it is not used. If this is a problem in your environment, you can compile with -Dlint. I often build this way: make CFLAGS='$(GCC_DEBUG_FLAGS)' as this provides -Dlint automatically.
I don’t know whether all sprintf() implementations for all operating systems respect the width/size specifier and allow non-0 terminated string.
All sprintf implementations work that way. This has been required by the C standard since C89 and is true for all C libraries in widespread use today. I tried rewriting asctime.c along the lines that you suggested (see the attached patch). On my platform (Fedora 21 x86-64, GCC 5.1.0) this made the zdump executable a tiny bit larger (7 bytes, for a new total of 33077 bytes). The wday_name and mon_name arrays are not likely to used elsewhere accidentally, as they're private to asctime_r and do not escape. Although it's not a big deal either way, it should be OK to leave this code alone.