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. But I have read the entire file and found no other conversion from time_t to 'long int'. So, committed and pushed. Bruno
