https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81091

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #0)
> libstdc++ seems to lack AC_SYS_LARGEFILE in configury and thus uses
> fopen/open
> in fstream and friends that can fail not only because of large files but
> files with large inode numbers depending on the underlying filesystem.

Richi, are you sure about that?

config/io/basic_file_stdio.cc does:

#ifdef _GLIBCXX_USE_LFS
        if ((_M_cfile = fopen64(__name, __c_mode)))
#else
        if ((_M_cfile = fopen(__name, __c_mode)))
#endif

And that macro should be set during configure, via:

dnl
dnl Check whether LFS support is available.
dnl
AC_DEFUN([GLIBCXX_CHECK_LFS], [
  AC_LANG_SAVE
  AC_LANG_CPLUSPLUS
  ac_save_CXXFLAGS="$CXXFLAGS"
  CXXFLAGS="$CXXFLAGS -fno-exceptions"
  AC_MSG_CHECKING([for LFS support])
  AC_CACHE_VAL(glibcxx_cv_LFS, [
    GCC_TRY_COMPILE_OR_LINK(
      [#include <unistd.h>
       #include <stdio.h>
       #include <sys/stat.h>
      ],
      [FILE* fp;
       fopen64("t", "w");
       fseeko64(fp, 0, SEEK_CUR);
       ftello64(fp);
       lseek64(1, 0, SEEK_CUR);
       struct stat64 buf;
       fstat64(1, &buf);],
      [glibcxx_cv_LFS=yes],
      [glibcxx_cv_LFS=no])
  ])
  if test $glibcxx_cv_LFS = yes; then
    AC_DEFINE(_GLIBCXX_USE_LFS, 1, [Define if LFS support is available.])
  fi
  AC_MSG_RESULT($glibcxx_cv_LFS)
  CXXFLAGS="$ac_save_CXXFLAGS"
  AC_LANG_RESTORE
])

So I think fstream is OK.

However, there are some bugs elsewhere due to not checking _GLIBCXX_USE_LFS and
so not using the largefile APIs:

src/c++11/random.cc:    _M_fd = ::open(fname, O_RDONLY);
src/c++11/random.cc:    _M_file = static_cast<void*>(std::fopen(fname, "rb"));

This should be OK in practice, because fname is guaranteed to be either
"/dev/random" or "/dev/urandom" (it seems unlikely that those devices will have
inode numbers that don't fit in 32 bits).

Nothing in src/filesystem and std/c++17/fs_* checks _GLIBCXX_USE_LFS or uses
the LARGEFILE64 APIs. I think those files should be built with
_FILE_OFFSET_BITS=64 so that stat, lstat, open, truncate etc. handle large
files automatically, without having to remember to use the LARGEFILE64 versions
explicitly.

Reply via email to