[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: off_t and dpkg_ar_member_get_size



Hi Niels,

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[1] 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[2].

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?

Thanks much,
Jonathan

[1] http://www.unix.org/version2/whatsnew/lfs20mar.html
[2] http://www.suse.de/~aj/linux_lfs.html


Reply to: