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

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

 



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.



[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux