Re: time_t on NetBSD/i386

[Jim Meyering]

Bruno Haible wrote:
> Hasso Tepper 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".

>> in lib/getdate.y:
>> verify (LONG_MIN <= TYPE_MINIMUM (time_t) && TYPE_MAXIMUM (time_t) <=
>>     LONG_MAX);
>
> 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.