[libcxx-commits] [libcxx] [libc++] Support file offsets larger than 2GB in basic_filebuf on 32-bit AIX and 32-bit glibc Linux (PR #215892)
Hubert Tong via libcxx-commits
libcxx-commits at lists.llvm.org
Mon Aug 17 10:20:56 PDT 2026
================
@@ -217,6 +217,20 @@ typedef basic_fstream<wchar_t> wfstream;
# pragma GCC system_header
# endif
+# if defined(_AIX) || (defined(__linux__) && defined(__GLIBC__))
+# define _LIBCPP_HAS_LARGEFILE_API 1
+# else
+# define _LIBCPP_HAS_LARGEFILE_API 0
+# endif
+
+# if _LIBCPP_HAS_LARGEFILE_API
+// On AIX and glibc on Linux, fopen64/fseeko64/ftello64 are not guaranteed to always be declared, so we declare them
+// here. They are not POSIX-reserved names, so we use __asm__ to guard them against a user #define.
+extern "C" FILE* __libcpp_fopen64(const char*, const char*) __asm__("fopen64");
+extern "C" long long __libcpp_ftello64(FILE*) __asm__("ftello64");
+extern "C" int __libcpp_fseeko64(FILE*, long long, int) __asm__("fseeko64");
+# endif
----------------
hubert-reinterpretcast wrote:
> glibc already decides to provide these names unconditionally in `stdio.h`, so I'm perfectly happy to make use of them unconditionally there.
Okay. @jakeegan, can you change the calls for the glibc path when you are back tomorrow?
> and if the answer is "yes, but it'll only be available in AIX version N" I'm perfectly happy to have a temporary workaround such as this one.
I have reached out to the AIX libc folks. However, note that, even when such a hypothetical AIX version is available, the workaround would be needed as long as libc++ supports older AIX versions. Do we need to block on their response?
https://github.com/llvm/llvm-project/pull/215892
More information about the libcxx-commits
mailing list