[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Lynx-dev] Year 2038 problem in handling cookie date
From: |
Bela Lubkin |
Subject: |
Re: [Lynx-dev] Year 2038 problem in handling cookie date |
Date: |
Wed, 31 Oct 2018 16:06:26 -0700 |
Thorsten Glaser wrote:
> address@hidden dixit:
>
> >Lynx crashes when accessing the site with 32-bit system.
> >I wrote an ad-hoc patch to prevent the crash.
>
> There are more bugs, for example:
>
> 996 if ((long) Start < 0)
>
> This will cause truncation, already on MirBSD/i386 and
> Linux/x32, which are ILP32 and use 64-bit time_t.
`Start' is a time_t, so on systems where time_t is already a 32-bit int
(i.e. `long'), that cast should have no effect. Whereas it breaks
64-bit time_t. So just remove the case: `if (Start < 0)'.
The caller in LYmktime.c also needs work:
| time_t LYmktime(char *string,
| int absolute)
| {
| #if USE_PARSDATE
| time_t result = 0;
|
| if (non_empty(string)) {
| CTRACE((tfp, "LYmktime: Parsing '%s'\n", string));
| result = parsedate(string, 0);
|
| if (!absolute) {
| if ((long) (time((time_t *) 0) - result) >= 0)
| result = 0;
| }
Again, I think no cast is what's wanted. If time_t is `long', the cast
has no effect; if `long long`, it breaks. Both halves of the
subtraction are of type `time_t' and POSIX insists that time_t must be a
signed integer type, so there is no need to cast it to make it signed.
Of course, then that `if' is equivalent to:
| if (result <= 0)
and the whole section can be replaced with:
| if (!absolute && result < 0) result = 0;
Also, beware that parsdate.y is the actual source of parsdate.c, via
modern-yacc-equivalent...
>Bela<