Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 3 Jul 2023 21:13:40 -0700
From:      Cy Schubert <Cy.Schubert@cschubert.com>
To:        Pedro Giffuni <pfg@freebsd.org>
Cc:        Warner Losh <imp@bsdimp.com>, src-committers <src-committers@freebsd.org>, "<dev-commits-src-all@freebsd.org>" <dev-commits-src-all@freebsd.org>, "<dev-commits-src-main@freebsd.org>" <dev-commits-src-main@freebsd.org>
Subject:   Re: git: 4456846a1a0d - main - bin/date: Upgrade calculations
Message-ID:  <20230703211340.1a26d3fa@slippy>
In-Reply-To: <1767168745.2134945.1688443634249@mail.yahoo.com>
References:  <202307040308.36438MTA093771@gitrepo.freebsd.org> <CANCZdfqMvf1QuS=fNQjRPe3YUbp1zPQW4aorh=VTRHk%2Bf_e8qg@mail.gmail.com> <1037448433.54513.1688441647903@mail.yahoo.com> <CANCZdfrSnS5Xq020jwsY-pgmTCJEn5Ka3Zr5vqt6OK%2Buawc4tA@mail.gmail.com> <1767168745.2134945.1688443634249@mail.yahoo.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 4 Jul 2023 04:07:14 +0000 (UTC)
Pedro Giffuni <pfg@freebsd.org> wrote:

>  (Sorry for top posting)
> Oh yes, the analysis is fine, and it is quicker to fix than what I had in=
 mind.
> I'll take a look at fixing it now, but due to external issues I may have =
to leave the fix for next weekend.
> Pedro.

You can't leave the tree broken for 5-7 days. Can you?


--=20
Cheers,
Cy Schubert <Cy.Schubert@cschubert.com>
FreeBSD UNIX:  <cy@FreeBSD.org>   Web:  https://FreeBSD.org
NTP:           <cy@nwtime.org>    Web:  https://nwtime.org

			e^(i*pi)+1=3D0

>=20
>     On Monday, July 3, 2023 at 11:00:51 PM GMT-5, Warner Losh <imp@bsdimp=
.com> wrote: =20
> =20
> =20
>=20
> On Mon, Jul 3, 2023, 9:34 PM Pedro Giffuni <pfg@freebsd.org> wrote:
>=20
>  Hmm ...
> Dragonfly has no armv7 or i386, so they didn't get it too wrong.I guess=
=C2=A0the int64_t would be a quick fix or another option, which I was consi=
deirng, was to look at unsigning it but taking care of the edge cases ... I=
 was too lazy for that.
> Please go ahead and do the quick fix ;)
>=20
> What makes you say it's a quick fix? If the calculations need 64 bits, in=
t64_t is the proper data type. How is that analysis wrong?
> Also, it's tradition that you should fix it...
> Warner =20




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20230703211340.1a26d3fa>