[PATCH 1/4] Remove off64_t from linux.h

[Felix Janda]

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