On Thu, 9 Mar 2017 14:53:11 -0800 Michael Forney <[email protected]> wrote:
> On Thu, Mar 9, 2017 at 2:10 PM, John Vogel <[email protected]> wrote: > > On Wed, 8 Mar 2017 09:47:15 -0800 > > Michael Forney <[email protected]> wrote: > > > >> I pushed a slightly amended version of this patch to my sbase branch at > >> https://github.com/michaelforney/sbase/commit/4b13b23a689da5fc01c2a26affe8ad8087c777bf. > >> > > > > I am running into strange behavior in both this patch, as well as my last > > one. > > I am pretty sure I tested it before, but I am not convinced I did so > > thoroughly. > > When setting the date, sometimes the result is as expected, sometimes the > > result is wildly off. I have run it through gdb. The broke down time seems > > to > > be set as expected. When inspecting struct tm date in either my patch or > > this > > one, I notice garbage values in parts of the tm struct that are not being > > set. I have tried two methods for addressing: (1) zeroing the date variable > > with > > memset and (2) declaring struct tm date as static. Both methods do the trick > > and setting the date is consistent with input. I also considered explicitly > > zeroing the members that are not touched, but since not all of them seem to > > be > > required by posix, I thought that zeroing the whole struct made more sense. > > > > I think it is safe to just set tm_sec to 0, and tm_isdst to -1 (so > that mktime will attempt to guess whether or not DST is in effect). > POSIX says that tm_wday and tm_yday are ignored, and the glibc manual > (and musl implementation) says that the non-standard fields tm_gmtoff > and tm_zone are also ignored. > This tests good here: diff --git a/date.c b/date.c index dcf2528..67f28d0 100644 --- a/date.c +++ b/date.c @@ -25,7 +25,7 @@ datefield(const char *s, size_t i) static void setdate(const char *s, struct tm *now) { - struct tm date; + struct tm date = { .tm_sec = 0, .tm_isdst = -1 }; struct timespec ts; switch (strlen(s)) {
