[libcxx-commits] [libcxx] [libc++] Support file offsets larger than 2GB in basic_filebuf on 32-bit AIX and 32-bit glibc Linux (PR #215892)

Nikolas Klauser via libcxx-commits libcxx-commits at lists.llvm.org
Mon Aug 17 04:22:58 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
----------------
philnik777 wrote:

FWIW my favourite resolution would be if AIX provided these APIs unconditionally somehow (e.g. a `__`-prefixed version; if the libc wants to make these `__asm__` aliases they're of course welcome to do so). glibc already decides to provide these names unconditionally in `stdio.h`, so I'm perfectly happy to make use of them unconditionally there.

I guess what I would like is if you could ask the libc folks internally to add such a name, 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.


https://github.com/llvm/llvm-project/pull/215892


More information about the libcxx-commits mailing list