octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #66399] fseek and ftell functions don't always


From: Markus Mützel
Subject: [Octave-bug-tracker] [bug #66399] fseek and ftell functions don't always work correctly on Win11 with filesizes >2GB
Date: Mon, 11 Nov 2024 10:21:55 -0500 (EST)

Update of bug #66399 (group octave):

         Planned Release:                    None => 10.1.0 (current default)

    _______________________________________________________

Follow-up Comment #7:

Maybe, this is caused by an upstream issue in Gnulib.

Looking only on their code paths for Windows: If I understand their
replacement functions for `fseek` and `ftell` correctly, they are effectively
calling `_fseeki64` and `_ftelli64` if the `off_t` type is smaller than 64-bit
and `fseek` and `ftell` otherwise.
However, even if the `off_t` type is 64-bit (or larger), `fseek` and `ftell`
still return `long` on Windows which is only 32-bit wide:
https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/ftell-ftelli64?view=msvc-170

So, they should probably be calling `_fseeki64` and `_ftelli64` on Windows
regardless of whether `off_t` is 32-bit or 64-bit.

The following patch to upstream gnulib fixes that for me:

diff --git a/lib/fseeko.c b/lib/fseeko.c
index 2c3b053a3b..30f8f70afe 100644
--- a/lib/fseeko.c
+++ b/lib/fseeko.c
@@ -31,7 +31,7 @@ fseeko (FILE *fp, off_t offset, int whence)
 # undef fseek
 # define fseeko fseek
 #endif
-#if _GL_WINDOWS_64_BIT_OFF_T
+#if _WIN32
 # undef fseeko
 # if HAVE__FSEEKI64 && HAVE_DECL__FSEEKI64 /* msvc, mingw since msvcrt8.0,
mingw64 */
 #  define fseeko _fseeki64
diff --git a/lib/ftello.c b/lib/ftello.c
index 88247bca8e..2f83c61c0e 100644
--- a/lib/ftello.c
+++ b/lib/ftello.c
@@ -34,7 +34,7 @@ ftello (FILE *fp)
 # undef ftell
 # define ftello ftell
 #endif
-#if _GL_WINDOWS_64_BIT_OFF_T
+#if _WIN32
 # undef ftello
 # if HAVE__FTELLI64 /* msvc, mingw64 */
 #  define ftello _ftelli64


It might make sense to also ask about that on the gnulib mailing list.



    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?66399>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]