problems with zoneinfo package passing VSX4 [forwarded with permission from grant at osf.org]

Arthur David Olson ado
Wed Oct 20 19:21:48 UTC 1993


> From grant at osf.org Tue Oct 19 17:47:42 1993
> Return-Path: <grant at osf.org>
> ...
> Message-Id: <9310192147.AA24813 at postman.osf.org>
> To: ado at elsie.nci.nih.gov
> Cc: grant at osf.org
> Subject: problems with zoneinfo package passing VSX4
> Date: Tue, 19 Oct 1993 21:47:37 +0000
> From: Grant Sullivan <grant at osf.org>
> ...
> 
> I am a contract software engineer currently working for the Open Software
> Foundation, Cambridge, MA.  I last sent mail to you in August of this year
> regarding my project to upgrade the next OSF/1 release to include the
> zoneinfo package.
> 
> I ended up using a sort of cut & paste approach to the project, using
> the BSD 4.4 version of ctime.c, based on your earlier work, as my code
> base for the libc changes, and "zic" additions.  I compared those sources
> with your June '93 kit, and merged in what appeared to be fixes.  I also
> included your entire June '93 zoneinfo source files.  I had to make a few
> other changes here and there to integrate everything into OSF/1.
> 
> As a final functional check of libc, I was asked to run the VSX4 test
> suite, before I would be allowed to formally submit the entire package
> into the OSF/1 source pool.
> 
> The VSX4 test suite found some problems with ctime(), localtime(), mktime(),
> strftime() and tzset().  Most of these problems turned out to have a single
> cause.  For example, correcting the failure in ctime() fixed the problems 
> with localtime(), strftime(), tzset(), and some of the mktime() problems.
> I thought you might be interested in knowing what changes I had to make to
> pass VSX4.  I am also stuck with one problem in mktime(), which you should
> be aware of, and for which I am having trouble developing a solution.
> 
> The VSX4 failure in ctime() involved a test case where TZ was set to
> 	TZ=(255 A's)0(255 B's)
> The number "255" corresponds to the POSIX.1 value for TZNAME_MAX.
> The VSX4 ANSI.os/time/ctime/T.ctime test Assertion 11 failed when the
> test checked the contents of tzname[] to see if it contained long A and
> B strings.   ctime() failed because tzset() return an error when it
> found that the value of stdlen+1+dstlen+1 was greater than sizeof sp->chars.
> The sizeof sp->chars was TZ_MAX_CHARS, set to "50" in tzfile.h.  I reset 
> TZ_MAX_CHARS to 2*(TZNAME_MAX+1), in order to fix the VSX4 failure.  
> Additionally in tzparse(), I changed the size checks for "stdlen" and
> "dstlen" to include upper limit checks against TZNAME_MAX, as follows:
> 	.
> 	.
>         } else {
>                 name = getzname(name);
>                 stdlen = name - stdname;
>                 if ( stdlen < _POSIX_TZNAME_MAX || stdlen > TZNAME_MAX )
>                         return -1;
> 	.
> 	.
>                 dstlen = name - dstname;        /* length of DST zone name */
>                 if ( dstlen < _POSIX_TZNAME_MAX_POSIX_TZNAME_MAX || dstlen > TZNAME_MAX )
>                         return -1;
>  	.
> 	.
> I also replaced "3" with _POSIX_TZNAME_MAX aboce.  The additional limit
> checks also make sure that the sum of the "std" and "dst" fields will
> not exceed 2*(TZNAME_MAX+1) even if TZ_MAX_CHARS should be set to
> something smaller.
> 
> The changes to tzfile.h and tzparse() resulted in eliminating the VSX4
> failures of ctime(), localtime(), strftime(), tzset(), and some of the
> mktime() failures.
> 
> I have some temporary fixes for the mktime() failures, but I have not
> been able to successfully fix the VSX4 failure of
> ANSI.os/time/mktime/T.mktime assertion 10.  Attempts I've made to fix
> it have tended to cause other mktime() assertions to fail, and vice
> versa.  I suspect a flaw in the loop logic, or loop termination logic
> in time2(), but it could also be a flaw in time1() or in localsub().
> 
> The VSX4 test of mktime fails when:
> 	TZ=GMT0BST-2,J81,J300
> and mktime() is called with the following tm structure:
>         expected.tm_sec  = 21;
>         expected.tm_min  = 0;
>         expected.tm_hour = 2;
>         expected.tm_mday = 27;
>         expected.tm_mon  = 9;
>         expected.tm_year = 88;
>         expected.tm_wday = -1;
>         expected.tm_yday = -1;
>         expected.tm_isdst = 1;
> VSX4 is expecting mktime() to return a value in the range 593913621 -
> 593913631 (allowing for the possibility that mktime() may include up to
> 10 additional leap seconds.  mktime() returned -1, instead.
> 
> I believe the expected value is correct.  VSX4 validates the mktime()
> returned value by calling localtime() with the expected number and
> comparing the expected and localtime()-generated tm structures.
> 
> I believe that VSX4 is expecting mktime() to behave in accordance to
> XPG4 with regards to how tm_isdst = 1 is handled on input to mktime().
> XPG4, "System Interfaces and Headers", page 275, says:
> 	A positive or zero value for tm_isdst causes the mktime()
> 	function to presume initially that Daylight Savings Time,
> 	respectively, is or is not in effect for the specified time.
> 	...
> mktime() seems to be having trouble when tm_isdst = 1, but the time/day
> the tm data specified is just past the end of the daylight savings time
> period.  In the case above, the time is 21 seconds past the transition
> back to standard time.
> 
> I have tried things like resetting tm_isdst = 0 and recalculating, but
> that works for some cases exercised by VSX4, but not for this
> particular case.
> 
> Have you heard of this VSX4 case?
> 
> One area that is suspect is the extended loop in time2() which is based
> on the "bits" counter.  The comments above the "normalize" function
> appear to pertain to this loop in time2():
> 
> /*
> ** Adapted from code provided by Robert Elz, who writes:
> **      The "best" way to do mktime I think is based on an idea of Bob
> **      Kridle's (so its said...) from a long time ago. (mtxinu!kridle now).
> **      It does a binary search of the time_t space.  Since time_t's are
> **      just 32 bits, its a max of 32 iterations (even at 64 bits it
> **      would still be very reasonable).
> */
> 
> I've added debugging statements to time2() to better understand what
> the "bits" logic is about, and found that "bits" counter would often
> get down to as low as "5" before jumping down to the next "for" loop.
> For the case tested by VSX4, timecnt = 136, so if this were truly "a
> binary search of the time_t space", I would not expect "bits" to drop
> below 21.  For the VXS4 test case, however, bits = 5 by the time the
> loop has found a value of "t" that is in range (t=593920800).  The
> calculates to a linear search, rather than a binary search, since the
> matching t = (sp->ats[37] + tt_gmtoff), and (37/2) is approx. (88-70)
> is approx. (initial bits - final bits ) (31 - 5).  I've tried setting
> the tm_year = 92, however, and found the loop went through the same
> number of cycles, so it I guess the search isn't really linear, but it
> seems to me it could be faster.
> 
> 
> I also noticed that your June '93 kit's version of timesub() contains
> additional code vs. the BSD 4.4 version.  I am wondering if this
> additional code is a bug fix?
> 
> Thanks for your assistance,
> Grant W. Sullivan,
> OSF/1 Commands & Libraries Group
> Open Software Foundation
> 11 Cambridge Center
> Cambridge, MA 02142
> grant at osf.org
> 617) 621-7249



More information about the tz mailing list