On 7/30/16 8:37 AM, Felix Janda wrote: > int64_t is guaranteed to have the correct size and signedness and is > always avaible because linux.h has a <inttypes.h> include. > > Fixes compilation error "unkown type name 'off64_t'" on linux when the > public header <xfs.h> is included without _LARGEFILE64_SOURCE or > _GNU_SOURCE defined. This bug was introduced in commit > cb898f157f8410a03cf5f3400baa1df9e5eecd33. Ok, I think that makes sense. So the progression was: Originally: typedef loff_t xfs_off_t; (But, "musl does not know loff_t") Next: typedef off64_t xfs_off_t; (But, can break compilation w/o special defines) Now: typedef int64_t xfs_off_t; which... I guess... satisfies everyone? A comment about why this, and not loff_t, might be worthwhile. So I have to ask, seeing __int64_t right below this int64_t; what's the difference/point in that? Does this need the __int64_t treatment for any other reason, can you tell? Just trying to avoid a 3rd change down the road. ;) Thanks, -Eric > Signed-off-by: Felix Janda <felix.janda@xxxxxxxxx> > --- > include/linux.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/linux.h b/include/linux.h > index 5614719..7653cac 100644 > --- a/include/linux.h > +++ b/include/linux.h > @@ -137,7 +137,7 @@ platform_discard_blocks(int fd, uint64_t start, uint64_t len) > #define EFSCORRUPTED EUCLEAN /* Filesystem is corrupted */ > #define EFSBADCRC EBADMSG /* Bad CRC detected */ > > -typedef off64_t xfs_off_t; > +typedef int64_t xfs_off_t; > typedef __uint64_t xfs_ino_t; > typedef __uint32_t xfs_dev_t; > typedef __int64_t xfs_daddr_t; > _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
