From: Felix Janda <felix.janda@posteo.de>
To: Dave Chinner <david@fromorbit.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 1/4] Remove off64_t from linux.h
Date: Mon, 20 Jun 2016 08:53:48 +0200 [thread overview]
Message-ID: <20160620065348.GA431@nyan> (raw)
In-Reply-To: <20160620020414.GH26977@dastard>
Dave Chinner wrote:
Thanks for asking for clarification.
> On Sat, Jun 18, 2016 at 04:52:38PM +0200, Felix Janda wrote:
> > The off64_t type is usually only conditionally exposed under the
> > feature test macro _LARGEFILE64_SOURCE (also defined by _GNU_SOURCE).
> > To make the public xfs headers more standalone therefore off64_t should
> > be avoided.
>
> "more standalone"?
>
> What does that mean?
Programs including the xfs headers while not defining _GNU_SOURCE or
_LARGEFILE64_SOURCE will not fail with compile errors. My previous
patch changing loff_t to off64_t had the unintented consequences that
downstreams of xfs-progs like ceph had to define _LARGEFILE64_SOURCE
on linux.
> And what does it mean for all the xfsprogs code that still uses
> off64_t?
off_t and off64_t are now synomyms and 64 bit on all architectures.
So no difference for code using off64_t.
Under some conditions there can be a difference for code using
off_t.
> i.e. if you are going to make xfsprogs fail to compile on configs
> that don't define off64_t, then it makes no sense to leave all the
> users of off64_t in the xfsprogs code....
On all supported systems except for current default linux (glibc)
configurations either there does not exist off64_t or it is the same
as off_t. The configure test will define _FILE_OFFSET_BITS=64 on linux
systems (i.e. enabling transparent large file support) with the result
that now even on linux off_t is 64 bit wide in all cases.
The "assert" ensures that programs using the xfs headers do not
compile when the expectation sizeof(off_t)=8 is not met. This makes
programs on 32 bit linux systems using the xfs headers but not
defining _FILE_OFFSET_BITS=64 not compile. I would consider this as
beneficial because such programs easily can have bugs regarding
support of files of size >2GB on 32 bit systems.
Felix
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2016-06-20 6:55 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-18 14:52 [PATCH 1/4] Remove off64_t from linux.h Felix Janda
2016-06-20 2:04 ` Dave Chinner
2016-06-20 6:53 ` Felix Janda [this message]
2016-06-20 23:18 ` Dave Chinner
2016-06-21 20:07 ` Felix Janda
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=20160620065348.GA431@nyan \
--to=felix.janda@posteo.de \
--cc=david@fromorbit.com \
--cc=xfs@oss.sgi.com \
/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