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

[Dave Chinner <david@fromorbit.com>]

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@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs