USE_ARRAY_FOR_64BIT_TYPES logic broken ?

Mike Frysinger vapier at gentoo.org
Thu Jan 12 15:58:59 EET 2006


On Thursday 12 January 2006 08:55, Christos Zoulas wrote:
> On Jan 11, 10:22pm, vapier at gentoo.org (Mike Frysinger) wrote:
> -- Subject: USE_ARRAY_FOR_64BIT_TYPES logic broken ?
>
> | i was cross-compiling file-4.16 for an amd64/uClibc host and when i tried
> | to use it natively, it kept giving me crap like:
> | /bin/bash: ERROR: error seeking (Invalid argument)
> |
> | i traced it back to configure setting the size of all the uint types
> | (8/16/32/64 bits) to 0 because it was a cross-compile, thus forcing the
> | logic of USE_ARRAY_FOR_64BIT_TYPES to be enabled
> |
> | for example, this code:
> |             if (dophn_core(ms, class, swap, fd,
> | #ifdef USE_ARRAY_FOR_64BIT_TYPES
> |                 (off_t)getu32(swap, elfhdr.e_phoff[1]),
> | #else
> |                 (off_t)getu64(swap, elfhdr.e_phoff),
> | #endif
> |                 getu16(swap, elfhdr.e_phnum),
> |                 (size_t)getu16(swap, elfhdr.e_phentsize)) == -1)
> |
> | that getu32() only swaps & uses the 2nd set of 32bits and disregards the
> | first set of 32bits (thus leading to my funky problem of bogus lseek()
> | calls)
>
> Yes, this logic is bogus and it will only work on big endian machines for
> small offsets. The small offsets problem is probably ok, but the big endian
> is not. We need to deal with endianness properly, at which point we should
> read both words :-)

are you going to write something or would you like me to post a patch ?  i 
could have one tonight for you ...
-mike



More information about the File mailing list