Hi Eli,
> largefile.m4 does:
>
> AC_CACHE_CHECK([for 64-bit st_size], [gl_cv_member_st_size_64],
> [AC_COMPILE_IFELSE(
> [AC_LANG_PROGRAM(
> [[#include <sys/types.h>
> struct stat buf;
> int verify_st_size_size[sizeof (buf.st_size) >= 8 ? 1 : -1];
> ]],
> [[]])],
> [gl_cv_member_st_size_64=yes], [gl_cv_member_st_size_64=no])
> ])
> if test $gl_cv_member_st_size_64 = no; then
> WINDOWS_64_BIT_ST_SIZE=1
> else
> WINDOWS_64_BIT_ST_SIZE=0
> fi
>
> This, @WINDOWS_64_BIT_ST_SIZE@ above is replaced with 1 when the
> default 'struct stat' has a 32-bit st_size.
Yes. This is intended.
> The problem with this redefinition is that 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.
Yes. I happened to encounter such a situation on a glibc system, many
years ago. This convinced me that
1) libraries should move to using 'large files' sooner than later,
2) it is not necessarily a particularly good idea to reference a
'struct stat' in the public API of a library.
> Which is exactly what happened to me
> while building the latest versions of GDB, which uses Gnulib, but
> links against the BFD library, which doesn't.
The BFD library should move to using 'large files' as soon as possible,
IMO. You don't want BFD to reject a .a file just because it's larger
than 2 GiB. You don't want BFD to report that a .a file is empty just
because it happens to be exactly 4 GiB in size.
libgcj was already 176 MB large. Binaries of 2 GiB size probably
already exist in projects that use C++ with a lot of templates.
> Why is this redefinition forced on programs that use Gnulib on
> Windows?
Gnulib does not force it. You can invoke gnulib-tool with option
'--avoid=largefile'; then it will not force support for large files
onto the package. But for the case of BFD and GDB, I would not
recommend that.
> I understand the desire to use 64-bit st_size when
> available, but it sounds like this could cause subtle and
> hard-to-debug problems, which are much worse than the 32-bit st_size
> limitation.
Use of files is a regular feature, not an exotic feature, of BFD and
GDB. I would therefore expect that such problems would typically be
caught by a test suite.
> IOW, it sounds like this redefinition is not needed where it works,
> and cannot be used safely where it doesn't work.
Mingw defines 'struct stat' also differently when the macro
_USE_32BIT_TIME_T is defined. It produces the same dangerous situation:
a type which can be defined differently in different compilation units.
This does not come from Gnulib; it comes from mingw. With the same
logic, you could say that 'struct stat' "cannot be used safely" on
mingw.
Different architectures have means to prevent weird situations when
code with different ABIs are linked together. For example, the floating-
point sizes in the MIPS ABI. Or the 'enum' sizes (short vs. int) in
the ARM or MIPS ABI. It would make sense to add such a linker check
to catch 'struct stat' mismatches as well. I guess that doesn't exist...
In the absence of such automated checks, you need a test suite.
Bruno
