[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ✘64-bit time_t on glibc 2.34 and up

From: Gary E. Miller
Subject: Re: ✘64-bit time_t on glibc 2.34 and up
Date: Mon, 16 Jan 2023 13:39:01 -0800

Yo Miroslav!

On Mon, 16 Jan 2023 10:17:00 +0100
Miroslav Lichvar <> wrote:

> On Thu, Jan 12, 2023 at 05:10:13PM -0800, Gary E. Miller wrote:
> > 4.  gpsd and ntpd always use 64-bit time_t going forward.  Admin
> > needs to mix and match.  
> I suspect that wouldn't work, at least generally. It would prevent
> gpsd/ntpd from using a library which has time_t in its API, e.g.
> I see timevals in libusb.h. 

I agree, it is terrible as a general case.  But gpsd is a specific case,
narrowed by the specific case where _TIME_SIZE_BITS is even an option.
Mostly Raspberry Pi, and similar, distros that are not 64-bit yet.

As for gpsd and libusb.h.  Gpsd uses none of the timeval calls that
libusb offers.  NTPsec does not use libusb at all.

> I think it is expected to be a distro policy to select which time_t is
> used in all applications and have that -D_TIME_BITS=64 in some global
> CPPFLAGS/CFLAGS followed by all packages.

Maybe, but Gentoo does not.  When the disrtos decide we'll have no
choice but to follow.

> gpsd could make it easier
> for users compiling it themselves and check some known locations of
> these global flags.

I know of none.  If you do, please forward them to us.

> > 5.  1st process to open SHM(0) wins, the other process checks the
> > size to know the contents.  
> This one makes most sense to me, if you feel you need to support both
> at the same time.

Except old apps stay around for decades.  Coding in data races is not
a good idea.  At least for shmTime, the current solution avoids that

> Instead of complicating the SHM support, I'd prefer if you deprecated
> it in favor of the SOCK or something else to avoid the security issue
> with untrusted applications creating the SHM segment before
> gpsd/ntpd/chronyd.

Now that you mention SOCK, we still do not have agreements on that.

> > Also note, chrony sockets have a similar problem:
> > 
> > #define SOCK_MAGIC 0x534f434b
> > struct sock_sample {
> >     struct timeval tv;
> >     double offset;
> >     int pulse;
> >     int leap;       // notify that a leap second is upcoming
> >     int _pad;
> >     int magic;      // must be SOCK_MAGIC
> > };  
> It could check the length of the message, see if the magic value
> at the end is correct, and convert the message to the expected time_t
> if it doesn't match the one that was used in compilation.

If you want to do that in chrony, then gpsd can do the same.

I would like ntpd to also be able to read the SOCK.

Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin

Attachment: pgppw1CddM_xf.pgp
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]