Re: time_t on NetBSD/i386

[Jim Meyering]

Bruno Haible wrote:
> Jim Meyering wrote:
>> >> time_t is 64 bits in recent NetBSD versions even on i386 platform,
>> >> therefore these assertations fail on it:
>> >>
>> >> in lib/mktime.c:
>> >> verify (long_int_year_and_yday_are_wide_enough,
>> >>     INT_MAX <= LONG_MAX / 2 || TIME_T_MAX <= UINT_MAX);
>> >
>> > I'm disabling this assertion; the code seems to be correct also with
>> > 64-bit 'time_t'.
>>
>> I'm still leery of disabling it, but can't put my finger on a precise
>> problem, so this isn't an official objection.
>>
>> I'm nearly certain you understand the issue, but your sentence above
>> suggests it is worth clarifying:
>> the possible problem is not with 64-bit time_t per se,
>> but rather with the combination of that *and* a "long int"
>> type that is no wider than "int".
>
> Yes. The naming of the variable 'long_int_year_and_yday_are_wide_enough'
> sounds as if Paul intended to be able to pass time_t values into 'year1'
> and 'yday1'. But this does not happen: all inputs are 'int'.
>
> Or maybe Paul meant that the entire time_t range can occur as result of
> mktime() with given 'int' inputs (in other words, that mktime is
> surjective)? I cannot see the rationale for such a requirement.
>
>> > This one is harder. It has already been reported for QNX [1][2].
>> > [1] http://lists.gnu.org/archive/html/bug-gnulib/2008-01/msg00161.html
>> > [2] http://lists.gnu.org/archive/html/bug-gnulib/2009-07/msg00111.html
>> >
>> > Here is a proposed patch. I checked all uses of 'time_t' in getdate.y and
>> > found only two conversions from time_t to 'long int', in the 'relunit' 
>> > rule:
>> >
>> >   | tSDECIMAL_NUMBER tSEC_UNIT
>> >       { $$ = RELATIVE_TIME_0; $$.seconds = $1.tv_sec; $$.ns = $1.tv_nsec; }
>> >   | tUDECIMAL_NUMBER tSEC_UNIT
>> >       { $$ = RELATIVE_TIME_0; $$.seconds = $1.tv_sec; $$.ns = $1.tv_nsec; }
>> >
>> > So this patch should handle it. Jim, Eric, opinions?
>>
>> I confess I'm not sure it's ok, but if something breaks,
>> we'll fix it and be sure to add a test case next time.
>>
>> So go ahead.
>
> The kind of breakage that we have to expect here is in the corner cases, with
> specially crafted input. It's not guaranteed that such a bug will visibly
> "break" something.

Of course.  I was concerned not about year numbers < 2038, and probably
not even time_t values < 2^32, but the corner in which year numbers
approach 2^31.