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

[Miroslav Lichvar]

On Tue, Jan 17, 2023 at 12:29:34PM -0800, Gary E. Miller wrote:
> > Ok, maybe gpsd is not impacted by the libraries it is using, but it
> > seems libgps is using some time_t fields, so they would need to be
> > replaced by int64_t or something to avoid breaking libgps applications
> > that don't use the same time_t.
> 
> I'll look at that.  Anything in particular?

"git grep -E '(timespec|timeval|time_t)' include/gps.h" shows:

    timespec_t time;            // Time of update
    timespec_t then;      // time of log entry, zero if invalid
    timespec_t utctime;
    time_t tow;                 // GNSS Epoch Time in ms
    timespec_t  mtime;  // time of measurement
    timespec_t mtime;           /* time of measurement: sec, nsec
    timespec_t activated;
    timespec_t cycle, mincycle;         // refresh cycle time in seconds
    timespec_t  real;
    timespec_t  clock;
    timespec_t online;          /* NZ if GPS is on line, 0 if not.
    timespec_t skyview_time;    // skyview time
        timespec_t time;
    timespec_t qErr_time;
extern time_t mkgmtime(struct tm *);
extern timespec_t iso8601_to_timespec(const char *);
extern char *timespec_to_iso8601(timespec_t t, char[], size_t len);

> Are you going to patch chronyd with your variable length sock idea?
> Current gpsd git head is a good test case for that.

It's now in chrony git. Let me know if it doesn't work for you.

-- 
Miroslav Lichvar