[Octave-bug-tracker] [bug #66399] fseek and ftell functions don't always work correctly on Win11 with filesizes >2GB

[Markus Mützel]

Follow-up Comment #19, bug #66399 (group octave):

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...



    _______________________________________________________

Reply to this item at:

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

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

signature.asc
Description: PGP signature