[Top][All Lists]

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

Re: Problematic redefinition of 'stat' and 'fstat'

From: Paul Eggert
Subject: Re: Problematic redefinition of 'stat' and 'fstat'
Date: Tue, 24 Dec 2019 10:51:54 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2

On 12/24/19 10:29 AM, Eli Zaretskii wrote:

> I'm not talking about file offsets,
> I'm talking about st_size only.

Why distinguish between the two? st_size is of type off_t in the standard POSIX
model, and that's what Gnulib-using programs expect.

> whatever BFD does
> or doesn't do, programs that link against it shouldn't have bugs
> caused by incompatible definitions of struct stat that is passed
> between the program and the library.

Sure, and the way to address this is for the BFD library to be built the same
way everything else is built. That's not in dispute; the only thing that's being
disputed is whether apps should be built with 32-bit off_t to match libbfd, or
libbfd should built with 64-bit off_t to match the apps. Since I would rather
not waste our valuable time to support 32-bit off_t which has been obsolescent
for decades, I suggest doing the latter.

> And mingw.org's MinGW works just fine if the
> Gnulib redefinitions are removed (i.e. WINDOWS_64_BIT_ST_SIZE is set
> to zero).

Coreutils programs would break badly in practice, if off_t is 32 bits.

If the fix is limited to MinGW programs that don't use Gnulib's largefile
module, it should be OK. But I expect that would be a more complicated fix than
what you're suggesting. And really, the better fix is to build libbfd with
64-bit off_t.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]