[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