64bit time_t patch

[Russ Allbery]

"S.P.Zeidler" <spz at serpens.de> writes:

> my system's innd survives news.daily so much better if I have:

> ---  snip ---
> --- cc.c.orig   2013-11-27 20:55:27.000000000 +0000
> +++ cc.c
> @@ -952,7 +952,7 @@ CCname(char *av[])
>              mode = (cp->MaxCnx > 0 && cp->ActiveCnx == 0) ? "paused" : "";
>              buffer_sprintf(&CCreply, true, ":%s:%ld:%s",
>                             cp->State == CScancel ? "cancel" : "nntp",
> -                           (long) Now.tv_sec - cp->LastActive, mode);
> +                           (long) (Now.tv_sec - cp->LastActive), mode);
>             break;
>         case CTlocalconn:
>              buffer_sprintf(&CCreply, true, ":localconn::");
> --- snip ---

> otherwise innd segfaults on ctlinnd name "" when peers are connected.
> (64bit time_t on a 32bit machine)

Yup, that looks right.

I suspect that will just be the first of a series of bugs that we'll find
after the decision to make time_t longer than a long.  :/  Lots of C code
was written under the assumption that wasn't possible.  For example, I bet
there are lots of places where we printf a time_t by casting it to a long
or an unsigned long.

-- 
Russ Allbery (eagle at eyrie.org)              <http://www.eyrie.org/~eagle/>

    Please send questions to the list rather than mailing me directly.
     <http://www.eyrie.org/~eagle/faqs/questions.html> explains why.