On Mon, Jun 20, 2016 at 08:53:48AM +0200, Felix Janda wrote:
> 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.
That needs to be in the patch description - it's the motivation for
the change (i.e. that downstream apps need to add new defines).
> > 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.
Right, I understand that there is a difference - what I'm asking for
is a description of the difference and an explanation of why:
$ git grep off64_t | wc -l
62
$
the other ~60 uses of off64_t in the xfsprogs code are not being
removed, too. i.e. if the code now won't compile if off_t isn't 64
bits, then why keep off64_t at all in any of the code?
Cheers,
Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx
|