From: Christoph Hellwig <hch@infradead.org>
To: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: Christoph Hellwig <hch@infradead.org>,
sandeen@sandeen.net, linux-xfs@vger.kernel.org
Subject: Re: [PATCH 20/26] xfs_db: report bigtime format timestamps
Date: Fri, 30 Oct 2020 08:23:58 +0000 [thread overview]
Message-ID: <20201030082358.GC303@infradead.org> (raw)
In-Reply-To: <20201029174544.GR1061252@magnolia>
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.
next prev parent reply other threads:[~2020-10-30 8:24 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-26 23:34 [PATCH v6 00/26] xfsprogs: widen timestamps to deal with y2038 Darrick J. Wong
2020-10-26 23:34 ` [PATCH 01/26] libxfs: create a real struct timespec64 Darrick J. Wong
2020-10-29 9:44 ` Christoph Hellwig
2020-10-26 23:34 ` [PATCH 02/26] libxfs: refactor NSEC_PER_SEC Darrick J. Wong
2020-10-29 9:44 ` Christoph Hellwig
2020-10-26 23:34 ` [PATCH 03/26] libfrog: define LIBFROG_BULKSTAT_CHUNKSIZE to remove dependence on XFS_INODES_PER_CHUNK Darrick J. Wong
2020-10-29 9:45 ` Christoph Hellwig
2020-10-29 9:45 ` Christoph Hellwig
2020-10-29 17:25 ` Darrick J. Wong
2020-10-30 8:20 ` Christoph Hellwig
2020-10-26 23:34 ` [PATCH 04/26] libfrog: convert cvttime to return time64_t Darrick J. Wong
2020-10-29 9:45 ` Christoph Hellwig
2020-10-26 23:34 ` [PATCH 05/26] xfs_quota: convert time_to_string to use time64_t Darrick J. Wong
2020-10-29 9:47 ` Christoph Hellwig
2020-10-29 17:32 ` Darrick J. Wong
2020-10-30 8:21 ` Christoph Hellwig
2020-11-16 20:45 ` Eric Sandeen
2020-10-26 23:34 ` [PATCH 06/26] xfs_db: refactor timestamp printing Darrick J. Wong
2020-10-29 9:47 ` Christoph Hellwig
2020-10-26 23:34 ` [PATCH 07/26] xfs_db: refactor quota timer printing Darrick J. Wong
2020-10-29 9:48 ` Christoph Hellwig
2020-10-26 23:34 ` [PATCH 08/26] xfs_logprint: refactor timestamp printing Darrick J. Wong
2020-10-29 9:48 ` Christoph Hellwig
2020-11-23 20:14 ` Eric Sandeen
2020-11-24 0:25 ` Darrick J. Wong
2020-10-26 23:35 ` [PATCH 09/26] xfs: explicitly define inode timestamp range Darrick J. Wong
2020-10-26 23:35 ` [PATCH 10/26] xfs: refactor quota expiration timer modification Darrick J. Wong
2020-10-26 23:35 ` [PATCH 11/26] xfs: refactor default quota grace period setting code Darrick J. Wong
2020-10-26 23:35 ` [PATCH 12/26] xfs: refactor quota timestamp coding Darrick J. Wong
2020-10-26 23:35 ` [PATCH 13/26] xfs: move xfs_log_dinode_to_disk to the log recovery code Darrick J. Wong
2020-10-26 23:35 ` [PATCH 14/26] xfs: redefine xfs_timestamp_t Darrick J. Wong
2020-10-26 23:35 ` [PATCH 15/26] xfs: redefine xfs_ictimestamp_t Darrick J. Wong
2020-10-26 23:35 ` [PATCH 16/26] xfs: widen ondisk inode timestamps to deal with y2038+ Darrick J. Wong
2020-10-26 23:35 ` [PATCH 17/26] xfs: widen ondisk quota expiration timestamps to handle y2038+ Darrick J. Wong
2020-10-26 23:36 ` [PATCH 18/26] libxfs: propagate bigtime inode flag when allocating Darrick J. Wong
2020-10-29 9:48 ` Christoph Hellwig
2020-10-26 23:36 ` [PATCH 19/26] libfrog: list the bigtime feature when reporting geometry Darrick J. Wong
2020-10-29 9:49 ` Christoph Hellwig
2020-10-26 23:36 ` [PATCH 20/26] xfs_db: report bigtime format timestamps Darrick J. Wong
2020-10-29 9:50 ` Christoph Hellwig
2020-10-29 17:45 ` Darrick J. Wong
2020-10-30 8:23 ` Christoph Hellwig [this message]
2020-11-16 21:16 ` Eric Sandeen
2020-11-16 22:41 ` Darrick J. Wong
2020-11-17 17:45 ` [PATCH v2 " Darrick J. Wong
2020-11-17 18:18 ` Eric Sandeen
2020-10-26 23:36 ` [PATCH 21/26] xfs_db: support printing time limits Darrick J. Wong
2020-10-29 9:50 ` Christoph Hellwig
2020-10-26 23:36 ` [PATCH 22/26] xfs_db: add bigtime upgrade path Darrick J. Wong
2020-10-29 9:51 ` Christoph Hellwig
2020-11-16 21:15 ` [PATCH v2 " Darrick J. Wong
2020-10-26 23:36 ` [PATCH 23/26] xfs_quota: support editing and reporting quotas with bigtime Darrick J. Wong
2020-10-29 9:51 ` Christoph Hellwig
2020-10-26 23:36 ` [PATCH 24/26] xfs_repair: support bigtime timestamp checking Darrick J. Wong
2020-10-29 9:52 ` Christoph Hellwig
2020-10-26 23:36 ` [PATCH 25/26] mkfs: format bigtime filesystems Darrick J. Wong
2020-10-29 9:52 ` Christoph Hellwig
2020-10-26 23:36 ` [PATCH 26/26] xfs: enable big timestamps Darrick J. Wong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201030082358.GC303@infradead.org \
--to=hch@infradead.org \
--cc=darrick.wong@oracle.com \
--cc=linux-xfs@vger.kernel.org \
--cc=sandeen@sandeen.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox