On Thu, 9 Mar 2017 14:53:11 -0800
Michael Forney <mforney_AT_mforney.org> wrote:
> On Thu, Mar 9, 2017 at 2:10 PM, John Vogel <jvogel4_AT_stny.rr.com> wrote:
> > On Wed, 8 Mar 2017 09:47:15 -0800
> > Michael Forney <mforney_AT_mforney.org> 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
_AT_@ -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)) {
Received on Fri Mar 10 2017 - 02:03:41 CET