Re: off_t and dpkg_ar_member_get_size
Niels Thykier wrote:
> I was considering to document the functions of ar.c when I noticed a
> possible issue in dpkg. It seems to me that dpkg_ar_member_get_size may
> (silently) truncate a "large file" when off_t is 32 bits. But I admit
> being uncertain here as I had difficulties finding a normative
> specification of the ar format.
On all Debian arches, off_t after "#define _FILE_OFFSET_BITS 64" (see
config.h) has 64 bits.
According to the LFS API the correct incantation is
c89 -D_LARGEFILE_SOURCE \
$(getconf LFS_CFLAGS) $(getconf LFS_LDFLAGS) \
a.c $(getconf LFS_LIBS)
but in practice using any old compiler (e.g., gcc) and defining
_LARGEFILE_SOURCE and _FILE_OFFSET_BITS with no extra libs works
fine and very portably and is what some people recommend.
dpkg uses AC_SYS_LARGEFILE.
> The issue is that dpkg_ar_member_get_size does not check for this case
> and will cause the "size" to overflow. In fact, it may even "flow back
> into positive" making it impossible for the caller to discover the that
> an overflow occured.
This sounds worth a patch for systems without large file support.
It also would improve clarity for readers (like me) who hadn't done
the math to check that 2 ** 64 >= 10 ** 10. Care to propose one?