Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 17 Oct 2022 12:42:09 -0600
From:      Alan Somers <asomers@freebsd.org>
To:        freebsd-hackers@freebsd.org
Subject:   Re: host unresponsive when setting time very far in the future
Message-ID:  <CAOtMX2jiqy50oR3c_Z3O_=0-ZO8OC579M-qgQn2w6uKE3YVTzw@mail.gmail.com>
In-Reply-To: <Y02ZUcbiUVl7sJuK@netmeister.org>
References:  <Y0y5cDu5aT/kLkuR@netmeister.org> <CADqw_gKvkhf6_N2UaZkxzcTau7Ewt%2BWBcx5=6aVmwC-BV_vbyA@mail.gmail.com> <Y01X%2B6cY2fdLzbqg@netmeister.org> <CANCZdfpduEOSZiYJboAHiuPZJvvieM3w68QY2QhxowcsEibxvA@mail.gmail.com> <Y02ZUcbiUVl7sJuK@netmeister.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Oct 17, 2022 at 12:05 PM Jan Schaumann <jschauma@netmeister.org> wr=
ote:
>
> Warner Losh <imp@bsdimp.com> wrote:
>
> > We do know that if the year (tm_year) overflows an int (32-bit signed),
> > we'll
> > have problems. It would be approximately year 2,147,483,648 (since I th=
ink
> > the limitation is signed, not unsigned, but if unsigned it's 4294967296
> > instead).
>
> Right, though since tm_year is defined as "year =C2=AD
> 1900", I'd expect to be able to reach 12/31 23:59:59
> in 2,147,485,547, as on e.g., NetBSD and Linux:
>
>  netbsd$ date -r 67768036191676799
>  Wed Dec 31 23:59:59 UTC 2147485547
>
>  linux$ date --date '@67768036191676799'
>  Wed Dec 31 11:59:59 PM UTC 2147485547
>
> But FreeBSD:
>  freebsd$ date -r 67768036191676799
>  date: invalid time
>  freebsd$ date -r 67767976233532799
>  Tue Dec 31 23:59:59 UTC 2147483647
>
> Kinda unclear to me how FreeBSD ended up with a
> tm_year value that's not 1900 based here?
>
> > Anything beyond that we know definitely won't work. Why we fall short
> > and "only" make it to year 1.561,694,399, I don't know the root
> > cause of. It's not even a nice, round multiple of the above...
>
> Regardless of the root cause, though, I think
> something somewhere should return EINVAL before the
> system freaks out. :-)
>
> -Jan

Definitely.  And the place that should do it is clock_ts_to_ct, where
the assertions were added in git rev 90a79ac5765 .  They should be
converted from assertions into EINVALs.
-Alan



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOtMX2jiqy50oR3c_Z3O_=0-ZO8OC579M-qgQn2w6uKE3YVTzw>