problems with tz-1994e `date'+mktime and Solaris 2.3 strftime
Paul Eggert
eggert at twinsun.com
Thu Apr 7 05:13:16 UTC 1994
From: guy at netapp.com (Guy Harris)
Date: Wed, 6 Apr 1994 16:44:48 -0700 (PDT)
> Sun's strftime invokes mktime, which is tz's
> mktime in this case.
Are you certain that it's not calling the 5.x "mktime()"? See below....
Yes. Here is the gdb output. Notice that the `mktime' is tz's (at
localtime.c:1404), whereas the strftime is Sun's. I include a
backtrace (the output of the GDB `where' command) just before the
point of failure -- Sun's strftime isn't handling the `%Z' format
correctly for some reason.
$ gdb -q date
(gdb) b main
Breakpoint 1 at 0x10edc: file date.c, line 85.
(gdb) r
Starting program: /net/twinsun/export/dark/u/eggert/src/lib/tz/date
Breakpoint 1, main (argc=1, argv=0xeffffc0c) at date.c:85
85 register int aflag = 0;
(gdb) b mktime
Breakpoint 2 at 0x140d0: file localtime.c, line 1404.
(gdb) c
Continuing.
Breakpoint 2, mktime (tmp=0xeffff9ec) at localtime.c:1404
1404 return time1(tmp, localsub, 0L);
(gdb) c
Continuing.
Breakpoint 2, mktime (tmp=0xeffff9ec) at localtime.c:1404
1404 return time1(tmp, localsub, 0L);
(gdb) where
#0 mktime (tmp=0xeffff9ec) at localtime.c:1404
#1 0xef77fc14 in strftime ()
#2 0x1171c in timeout (fp=0x28220, format=0x145b0 "%X %Z %Y", tmp=0xeffffae8) at date.c:526
#3 0x11628 in display (format=0x0) at date.c:491
#4 0x112d0 in main (argc=1, argv=0xeffffc0c) at date.c:288
(gdb) c
Continuing.
Breakpoint 2, mktime (tmp=0xeffff93c) at localtime.c:1404
1404 return time1(tmp, localsub, 0L);
(gdb) c
Continuing.
Wed Apr 6 19:44:40 1994
Program exited normally.
(gdb)
> Perhaps Sun's strftime expects something out of
> mktime that tz's mktime does not provide. I wonder why it calls
> mktime at all?
5.x doesn't have "tm_zone" nor "tm_gmtoff" in "struct tm", does it?
That's correct -- the SunOS 5.3 <time.h> uses a minimal `struct tm'.
C library code in SVR4-derived systems like 5.x, when calling
routines not in, I think, the ANSI C name space, prepend an
underscore to the name of the routine.
That's true. But since mktime _is_ in the ANSI C name space, Sun
doesn't have to (and doesn't) play that game with mktime. There is no
`_mktime' in the library, and if you redefine mktime, as the tz
package's `date' does, you're on your own.
Could the 5.x "strftime()" be calling the 5.x "tzset()" rather than the
"tzset()" from the library you've built?
No. Here is a GDB session that shows this. tzset is being called only
from localtime().
$ gdb -q ./date
(gdb) b main
Breakpoint 1 at 0x10edc: file date.c, line 85.
(gdb) r
Starting program: /net/twinsun/export/dark/u/eggert/src/lib/tz/./date
Breakpoint 1, main (argc=1, argv=0xeffffc0c) at date.c:85
85 register int aflag = 0;
(gdb) b tzset
Breakpoint 2 at 0x132fc: file localtime.c, line 868.
(gdb) b _tzset
Breakpoint 3 at 0xef782dac
(gdb) c
Continuing.
Breakpoint 2, tzset () at localtime.c:868
868 name = getenv("TZ");
(gdb) where
#0 tzset () at localtime.c:868
#1 0x133e8 in localsub (timep=0xeffffae4, offset=0, tmp=0x24bb8) at localtime.c:920
#2 0x1350c in localtime (timep=0x24800) at localtime.c:962
#3 0x11598 in display (format=0x0) at date.c:487
#4 0x112d0 in main (argc=1, argv=0xeffffc0c) at date.c:288
(gdb) c
Continuing.
Wed Apr 6 22:11:44 1994
Program exited normally.
More information about the tz
mailing list