Gnulib was updated to a newer version on the default branch of the Octave repository. That will probably be used to eventually release Octave 10.x.

Not sure what you mean by "updating gnulib on my computer". Gnulib is more like a build-time dependency (not a dependency that can be updated after the Octave binaries have been built). So, you'd need to build Octave yourself if you'd like to update to a newer gnulib version before Octave 10 will be released.
Alternatively, you could use the build artifacts of the Windows CI on GitHub to test an un-stable build from the default branch of the Octave repository:
https://wiki.octave.org/Continuous_Build#GitHub_build_artifacts

Can this bug be closed?  It seems that the original bug report, about fseek and ftell, has been fixed by updating gnulib.  However, this may have created new and different problems.  If the original issue is fixed then I think this report should be closed.

OK. Can you open a separate bug report about MacOS failure.
I should be able to get my hands on Mac soon.

Dmitri.
--

Some tests have started to fail on macOS 14 after updating gnulib:
https://github.com/gnu-octave/octave/actions/runs/11843167971/job/33003488322#step:13:67271

>>>>> processing /Users/runner/work/octave/octave/test/file-encoding/file-encoding.tst
***** test
 help_str = get_help_text ("test_CP1252");
 ## The help text contains the string "ÄÖÜäöü ŠŽšž".  Compare to the
 ## corresponding UTF-8 byte sequence to make sure this test is independent
 ## of how this .tst file is interpreted.
 ref_str = char ([195 132 195 150 195 156 195 164 195 182 195 188 32 ...
                  197 160 197 189 197 161 197 190]);
 assert (strfind (help_str, ref_str));
!!!!! test failed
file_reader::get_input: converting from codepage 'windows-1252' to UTF-8: Function not implemented
***** test
 path_orig = path ();
 unwind_protect
   addpath ("CP1251");
   help_str = get_help_text ("test_CP1251");
   ## The help text contains the string "ДЦЬдць ЉЋљћ".  Compare to the
   ## corresponding UTF-8 byte sequence to make sure this test is independent
   ## of how this .tst of how this .tst file is interpreted.
   ref_str = char ([208 148 208 166 208 172 208 180 209 134 209 140 32 ...
                    208 137 208 139 209 153 209 155]);
   assert (strfind (help_str, ref_str));
 unwind_protect_cleanup
   path (path_orig);
   dir_encoding (canonicalize_file_name ("CP1251"), "delete");
 end_unwind_protect
!!!!! test failed
file_reader::get_input: converting from codepage 'windows-1251' to UTF-8: Function not implemented
***** test
 clear all;  # make sure files are re-parsed
 path_orig = path ();
 unwind_protect
   addpath (canonicalize_file_name ("CP1251"));
   help_str = get_help_text ("test_CP1251");
   ## The help text contains the string "ДЦЬдць ЉЋљћ".  Compare to the UTF-8
   ## byte sequence to make sure this test is independent of how this .tst
   ## file is interpreted.
   ref_str = char ([208 148 208 166 208 172 208 180 209 134 209 140 32 ...
                    208 137 208 139 209 153 209 155]);
   assert (strfind (help_str, ref_str));
 unwind_protect_cleanup
   path (path_orig);
   dir_encoding (canonicalize_file_name ("CP1251"), "delete");
 end_unwind_protect
!!!!! test failed
file_reader::get_input: converting from codepage 'windows-1251' to UTF-8: Function not implemented
***** test <*62780>
 ## wrap in "evalc" to suppress output to the log
 evalc ('oruntests (".");');
!!!!! regression: https://octave.org/testfailure/?62780
native2unicode: iconv() is not supported.  Installing GNU libiconv and then re-compiling Octave could fix this.
***** test <*62780>
 unwind_protect
   dir_encoding (canonicalize_file_name ("CP1251"), "windows-1251");
   ## use "evalc" to suppress output to the log
   evalc ('oruntests ("CP1251");');
 unwind_protect_cleanup
   dir_encoding (canonicalize_file_name ("CP1251"), "delete");
 end_unwind_protect
!!!!! regression: https://octave.org/testfailure/?62780
native2unicode: iconv() is not supported.  Installing GNU libiconv and then re-compiling Octave could fix this.
***** test <*62780>
 old_mfile_encoding = mfile_encoding ("windows-1251");
 unwind_protect
   ## use "evalc" to suppress output to the log
   evalc ('oruntests ("CP1251");');
 unwind_protect_cleanup
   mfile_encoding (old_mfile_encoding);
 end_unwind_protect
!!!!! regression: https://octave.org/testfailure/?62780
native2unicode: iconv() is not supported.  Installing GNU libiconv and then re-compiling Octave could fix this.
***** test <*62780>
 path_orig = path ();
 unwind_protect
   addpath (canonicalize_file_name ("CP1251"));
   ## use "evalc" to suppress output to the log
   evalc ('oruntests ("CP1251");');
 unwind_protect_cleanup
   path (path_orig);
   dir_encoding (canonicalize_file_name ("CP1251"), "delete");
 end_unwind_protect
!!!!! regression: https://octave.org/testfailure/?62780
native2unicode: iconv() is not supported.  Installing GNU libiconv and then re-compiling Octave could fix this.

They are still passing on macOS 14.

I don't have access to a macOS system and can't tell whether that is related to the update or not. But we might just be trading a bug on one platform for a different bug on another platform if we update now...

We usually try to not update gnulib for minor releases.
I don't know if this warrants an exception.

Bruno Haible fixed the issues with large files on Windows in gnulib.

I updated gnulib in Octave to a commit that contains these changes:
https://hg.savannah.gnu.org/hgweb/octave/rev/226a392f0818

Marking as ready for test.

> Should we also avoid to use `fseek` with pipes?

C code should avoid fseek; always use fseeko. Although fseek should work with small-enough offsets why ask for trouble?

If you use fseeko on a pipe, it should either work (if it's a small seek that stays within the I/O buffer) or fail with errno=ESPIPE; it can also fail for other reasons.

I don't know about std::fseeko, as I don't use C++. However, Gnulib does attempt to make its fseeko replacement visible to C++ using the usual namespace rules. Perhaps this is relevant to your problem, but you'll need a C++ expert to diagnose it.

I see that you do appear to be trying to work around the issue with octave_fseeko_wrapper, which I don't fully understand. If you have that, why use std::fseek in libinterp/corefcn/gl2ps-print.cc? Shouldn't that code use octave_lseeko_wrapper instead?

Bruno Haible knows C++ and MS-Windows (I know neither), and I hope he'll reply again on bug-gnulib and clear up some of the confusion here.

I posted the octave-fseeko.diff patch now.

From what you write, this patch won't fix the problem. However, it is a bit of an improvement, as it makes Octave's dependence on fseeko explicit rather than implicit, and it also says explicitly that Octave does not use fseek and ftell (which it should not be doing, though it does in some places other than those mentioned in the patch).

As Bruno Haible mentioned on the Gnulib mailing list in "Re: fseek and ftell with large files on Windows", this is not a bug in Gnulib.

To fix the problem, I suppose Octave can use fseeko/ftello internally instead of fseek/ftell, and change its bootstrap.conf to specify the fseeko and ftello modules instead of the fseek and ftell modules.

A quick glance at the source code indicates that Octave is already using fseeko in most places, but there are some places where it's not. I'm attaching a little patch "octave-fseeko.diff" to show the first place I found. Most likely further fixes along these lines would be needed.

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.

I confirm the problem on Win11 with 9.2.1 using
"Fedora-Workstation-Live-x86_64-41-1.4.iso" as an example
(this is just a 2+GB file I had at hand).
It also works as expected on linux:

octave:1> fn = "Fedora-Workstation-Live-x86_64-41-1.4.iso"
fn = Fedora-Workstation-Live-x86_64-41-1.4.iso
octave:2>  ls ("-lh", fn)
-rw-r--r-- 1 dima dima 2.3G Oct 29 16:02 Fedora-Workstation-Live-x86_64-41-1.4.iso
octave:3> fid = fopen(fn)
fid = 19
octave:4> ftell(fid)
ans = 0
octave:5> [dseq, cnt] = fread(fid, 320, "uint8");
octave:6> ftell(fid)
ans = 320
octave:7> fseek(fid, 0, "bof")
ans = 0
octave:8> ftell(fid)
ans = 0

So it appears to be one one of those Windows thing.
May be somebody can add CC to markus <mmuetzel>

Dmitri.
--

Thanks, so that doesn't make a difference.

Well, next question is if the file encoding could be interfering. But I'm unfamiliar with that part of Octave's code.

Would it be possible to upload (a first part, say a good part beyond the 640 char limit that you invoked) of that file 'Data_256Seg±1000mVRng4GSampRate_1_1.dat' so that we can try ourselves?

BTW, a hint:
If you enter the command
 format compact
in the terminal Octave doesn't echo empty lines in its output. Makes for more easy reading here (less scrolling needed)
I have that command in my .octaverc

Can you try with "bof" and "eof" rather than SEEK_SET and SEEK_END and report back, please?