[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:08:51 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2

On 12/24/19 9:25 AM, Eli Zaretskii wrote:
> if the default definition
> of 'struct stat' uses 32-bit st_size field, then linking a program
> against a library which was compiled with that default (i.e. without
> using the Gnulib overrides) will produce a buggy program, if it passes
> 'struct stat' to the library

Decades ago most GNU programs moved to 64-bit file offsets and never looked
back. If Gnulib defaulted to 32-bit file offsets on the all-too-many platforms
where it's the default, this would likely cause more problems than it would 

If it's really the intent to build the BFD library with 32-bit file offsets,
folks could build the library twice, once with 32-bit file offsets (for programs
that never need to access large files), and once with 64-bit file offsets (for
everybody else). Better yet, the BFD library could support both kinds of callers
via the usual library trickery.

Also, perhaps you could ask MinGW to fix their struct stat so that it works OK
when small-file and large-file object code is intermixed, so long as all files
accessed are small. After all, this problem won't go away even if we fiddle with

reply via email to

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