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

[Felix Janda <felix.janda@posteo.de>]

Dave Chinner wrote:
> 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).

Sure.

> > > 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?

On 32bit systems using glibc the following changes happen:

1. off_t is now 64 bit instead of 32 bit
2. all functions and structures using off_t are mapped to versions
   using the 64 bit off_t

1. means that off_t and off64_t are now equivalents, whereas 2. means
that struct stat and struct stat64, open() and open64() and many others
become equivalent.

Because, in addition to off64_t, "64"-functions and structures are
used very consistently in the code I have hold off sending a patch
changing these. I recall also seeing in some commit messages that at
some sites off64_t was changed to int64_t (or __int64_t...) for header
portability; for these sites it might be nice to change back to off_t.

Grepping the code I found one occurence in fsr/xfs_fsr.c of off_t (not
off64_t) which will be affected by the change (on 32bit linux). Right
now the F_GETLK fcntl with the struct flock is used there instead of
F_GETLK64 with struct flock64. The current usage is ok because the
off_t arguments are only used for the value 0 which happily fits into
variables of any size. After the change, the fcntl F_GETLK64, struct
flock64 and off64_t will be used instead, leading to no visible change
in behavior.

Felix

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