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

[Eli Zaretskii]

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

I was only talking about 32-bit MinGW builds, not about anything else.

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

This is beside the point.  First, I'm not talking about file offsets,
I'm talking about st_size only.  More importantly, 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.

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

The situation with 'stat' on Windows is messy, especially if one wants
to support 32-bit builds on XP and older versions.  MinGW already
includes quite a bit of trickery and various optional features to DTRT
with that mess.  How to resolve that in each and every program is
something the person who builds or ports it should consider and
decide.  Gnulib should not force any such decisions, it should just go
with whatever was decided, and only augment the system-provided 'stat'
in the usual corner cases (trailing slash etc.).

In any case, as I said in my original report: MinGW64 doesn't need
this tweaking, and it already tossed support for XP anyway, so it
needs just one variant of struct stat, the others are AFAIU just
ballast from the past.  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).  So I'm suggesting to drop these redefinitions for all
flavors of MinGW, as AFAICT they do much more harm than help.

Thanks.