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