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

[Eli Zaretskii]

> Cc: address@hidden
> From: Paul Eggert <address@hidden>
> Date: Tue, 24 Dec 2019 10:51:54 -0800
> 
> 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?

Because one is a member of a struct, the other is just a scalar.
Passing a scalar to a function imposes much fewer restrictions that
passing a struct with such a member.

> st_size is of type off_t in the standard POSIX
> model, and that's what Gnulib-using programs expect.

In the abstract sense, yes.  But I'm talking about practical aspects
of the issue, and they are very different.  Especially since various
versions of Windows have different and sometimes incompatible versions
of struct stat in their runtime.  Like I said: it's a mess, if one
wants to support 32-bit programs that run on all of those versions.

> 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.

So you are saying Gnulib will not change what it does with this stuff,
and instead every library that happens to use struct stat will have to
tweak the struct definition so that it fits the Gnulib's idea?  I
guess that's an answer, albeit a slightly disappointing one.

> > 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.

Coreutils don't build with MinGW for ages, so the off_t issue will be
the least of the problems for whoever will want to build them with
MinGW.

> 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.

It isn't more complicated.  Just avoiding to set
WINDOWS_64_BIT_ST_SIZE is all that's needed.  I tested that.

> And really, the better fix is to build libbfd with 64-bit off_t.

That is something for the BFD maintainers to decide, which I'm not.  I
just compile it to build GDB, that's all.  You are welcome to work
with BFD developers to get them to use Gnulib, and if you succeed, the
issue with BFD will be fixed.  All the rest of the libraries which
don't use Gnulib will still have the same problem, though.