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