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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.