Home • About Us • A-Z Index • Search * Contact Us • Register • Login • Press • Shop

The Open Brand -- Problem Reporting and Interpretations System

Problem Report 0269 Details

Help Show help | Quick Search | Submit a Test Suite Support Request | Click here to view your privileges

This page provides all information on Problem Report 0269.

Report 0269 Actions

    Problem Report Number 0269
    Submitter's Classification Test Suite problem
    State Resolved
    Resolution Test Suite Deficiency (TSD)
    Problem Resolution ID TSD.X.0269
    Raised 1997-11-12 08:00
    Updated 2003-03-13 08:00
    Published 1997-11-25 08:00
    Product Standard Internationalised System Calls and Libraries (XPG4)
    Certification Program The Open Brand certification program
    Test Suite VSX4 version 4.4.2
    Test Identification ANSI.os/time/mktime 18 19
    Problem Summary TSD4.269 The test program sets INT_MAX to tm_year in the struct tm and calls mktime(). In mktime(), it calculates the seconds as follows: secs += SEC_PER_YEAR * (timeptr->tm_year - 70) + SEC_PER_DAY * ((timept...
    Problem Text
    The test program sets INT_MAX to tm_year in the struct tm and calls
    mktime(). In mktime(), it calculates the seconds as follows:

    secs += SEC_PER_YEAR * (timeptr->tm_year - 70) +
    SEC_PER_DAY * ((timeptr->tm_year + 3)/4 - 1 - LEAP_TO_70);

    where SEC_PER_YEAR is (365 * 24 * 60 * 60),
    SEC_PER_DAY is (24 * 60 * 60), and
    LEAP_TO_70 is (70/4).

    Here, secs is defined as a 'time_t' variable. In K64/L64, secs is 64-bit
    variable. In K64/L32 and K32/L32, secs is 32-bit variable.
    If INT_MAX is set in timeptr->tm_year, secs will be 67769427732451200
    in K64/L64. But, in K64/L32 (and K32/L32), as the above expression
    causes overflow, secs will be 2057380096.
    mktime() invokes localtime_u() with secs, and localtime_u() invokes
    offtime_u(). The following is extracts from offtime_u():

    long days;
    int y;
    int yleap;

    days = *clock / SECS_PER_DAY;
    y = EPOCH_YEAR;
    if (days >= 0)
    for (;;) {
    yleap = isleap(y);
    if (days < __year_lengths[yleap])
    break;
    ++y;
    days = days - __year_lengths[yleap];
    }
    else
    ......

    Here, *clock has the same value as secs in mktime(). So, offtime_u() is
    calculating how many years *clock (seconds) corresponds to. Of course,
    it is about INT_MAX years in K64/L64. But it's only about 66 years
    in K64/L32 and K32/L32. So, in K64/L64, the above for-loop will be repeated
    about INT_MAX - EPOCH_YEAR (more than two billion) times. This is the reason
    why the execution of the test program in K64/L64 takes so much time.
    Test Output
    400|311 18 1 19:42:17|IC Start
    200|311 18 19:42:17|TP Start
    520|311 18 00027138 2 1|child process timed out
    220|311 18 2 19:42:42|UNRESOLVED
    410|311 18 1 19:42:42|IC End
    400|311 19 1 19:42:42|IC Start
    200|311 19 19:42:42|TP Start
    520|311 19 00027138 2 1|child process timed out
    220|311 19 2 19:43:07|UNRESOLVED
    410|311 19 1 19:43:07|IC End

    Review Information

    Review Type TSMA Review
    Start Date null
    Completed null
    Status Complete
    Review Recommendation No Resolution Given
    Review Response
    This problem raises an interesting question as to how long a call
    should take to process a valid argument. While it is accepted that
    this is not specified in the XSH, a user has some expectation as to
    the processing time that a call to mktime() can incur.

    Perhaps the algorithm used could be simplified by recognising that
    the calendar repeats after 400 years, which including leap days
    amounts to 12622780800 seconds, by my calculations. Calculating the
    modulus respective to 12622780800 would then simplify the calculation
    and allow mktime() to return in a reasonable amount of time.

    However, since this seems to be a quality of implementation issue rather
    than a conformance issue, it is recommended that a waiver is granted
    on the grounds of a test suite deficiency.

    It should be noted that it will be difficult to correct this deficiency
    unless additional information is provided as to how long the test suite
    should allow for an operation of this type.

    Review Type SA Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution Test Suite Deficiency (TSD)
    Review Conclusion
    This is an agreed Test Suite Deficiency.

    Problem Reporting System Options:

     

    Back   

Contact the Certification Authority