Re: [Lynx-dev] Year 2038 problem in handling cookie date

[Bela Lubkin]

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<