Re: [PATCH 20/26] xfs_db: report bigtime format timestamps

Christoph Hellwig
2020-10-30T08:24:03Z

On Thu, Oct 29, 2020 at 10:45:44AM -0700, Darrick J. Wong wrote:
> On Thu, Oct 29, 2020 at 09:50:10AM +0000, Christoph Hellwig wrote:
> > > +static void
> > > +fp_time64(
> > > + time64_t sec)
> > > {
> > > + time_t tt = sec;
> > > char *c;
> > > +
> > > + BUILD_BUG_ON(sizeof(long) != sizeof(time_t));
> >
> > Why?
>
> Trying to make the best of a braindead situation. IIRC C99/11/18 don't
> provide a specific definition of what time_t is supposed to be. POSIX
> 2017 seems to hint that it should be an integer seconds counter, but
> doesn't provide any further clarity. (And then says it defers to ISO C,
> having made that allusion to integerness.)

I'm pretty sure the x32 ABI has a time_t that is bigger than long,
which broken POSIX semantics.

> Hence adding a trap so that if xfsprogs ever does encounter C library
> where time_t isn't a long int, we'd get to hear about it. Granted that
> further assumes that time_t isn't a float, but ... ugh.
>
> I guess this could have assigned sec to a time_t value and then compared
> it back to the original value to see if we ripped off any upper bits.

I think the standard way would be an intmax_t local variable that the
value is assigned to.