bug-gnulib
[Top][All Lists]
Advanced

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

Re: fseeko issues in mys2/mingw64


From: Bruno Haible
Subject: Re: fseeko issues in mys2/mingw64
Date: Sat, 25 Jan 2020 21:07:56 +0100
User-agent: KMail/5.1.3 (Linux/4.4.0-171-generic; KDE/5.18.0; x86_64; ; )

Hi John,

> Running in a native configure in msys2/mingw64 and make builds ok;
> 
> 
> The following modules are added to libnu.a:
> freading.o stat-time.o unistd.o fflush.o fpurge.o fseek.o fseeko.o 
> fstat.o lseek.o msvc-inval.o msvc-nothrow.o stat-w32.o
> 
> Running the app:
> 
> ./bigtest.exe
> test big file
> creating big file ...done
> sizeof(off_t)=8
> seek status=-1
> tell pos=0
> 
> Running in debug, and doing a break on _lseek
> 
> (gdb) bt
> #0  0x00007ffd2f7ad1cb in msvcrt!_lseek () from 
> C:\WINDOWS\System32\msvcrt.dll
> #1  0x00000000004016e7 in rpl_lseek (fd=3, offset=offset@entry=0,
>      whence=whence@entry=1) at lseek.c:69
> #2  0x0000000000401636 in rpl_fseeko (
>      fp=fp@entry=0x7ffd2f81fa90 <msvcrt!_iob+144>, offset=offset@entry=0,
>      whence=whence@entry=2) at fseeko.c:45
> #3  0x000000000040838c in main () at main.cpp:41
> 
> And for the lseek call that fails:
> 
> (gdb) bt
> #0  0x00007ffd2f7ad1cb in msvcrt!_lseek () from 
> C:\WINDOWS\System32\msvcrt.dll
> #1  0x00000000004016e7 in rpl_lseek (fd=3, offset=offset@entry=0,
>      whence=whence@entry=2) at lseek.c:69
> #2  0x0000000000401683 in rpl_fseeko (
>      fp=fp@entry=0x7ffd2f81fa90 <msvcrt!_iob+144>, offset=offset@entry=0,
>      whence=whence@entry=2) at fseeko.c:117
> #3  0x000000000040838c in main () at main.cpp:41

>From these backtraces I infer that:
- gnulib's _GL_WINDOWS_64_BIT_OFF_T is not defined, because mingw64 defines
  off_t to a 64-bit type already, due to _FILE_OFFSET_BITS=64, which is
  ensured by AC_SYS_LARGEFILE.
- mingw does a '#define lseek _lseeki64' in this situation (for proper
  large file support).
- The 'undef lseek' in gnulib's unistd.h and lseek.c undoes it.

The patch below should fix it. I've pushed it already, but I would appreciate
your feedback.

> It is entering the lseek call which is really _lseek (parameters that 
> are long) rather than 64bit instead of using the _lseeki64 call.
> 
> #if _GL_WINDOWS_64_BIT_OFF_T
>    return _lseeki64 (fd, offset, whence);
> #else
>    return lseek (fd, offset, whence);
> #endif
> 
> 
> Looking for _GL_WINDOWS_64_BIT_OFF_T, it only gets set in 
> lib/sys_types.in.h if WINDOWS_64_BIT_OFF_T is set.
> 
> Should lseek.c  call _lseeki64 regardless of _GL_WINDOWS_64_BIT_OFF_T 
> value ...

Yup. You hit the nail on the head.


2020-01-25  Bruno Haible  <address@hidden>

        lseek: Fix the override to not undo the effects of AC_SYS_LARGEFILE.
        Reported by John Donoghue <address@hidden> in
        <https://lists.gnu.org/archive/html/bug-gnulib/2020-01/msg00146.html>.
        * lib/lseek.c (rpl_lseek): When AC_SYS_LARGEFILE has enabled a 64-bit
        off_t on mingw, invoke _lseeki64 instead of lseek.

diff --git a/lib/lseek.c b/lib/lseek.c
index 013f665..b249839 100644
--- a/lib/lseek.c
+++ b/lib/lseek.c
@@ -63,7 +63,7 @@ rpl_lseek (int fd, off_t offset, int whence)
       return -1;
     }
 #endif
-#if _GL_WINDOWS_64_BIT_OFF_T
+#if _GL_WINDOWS_64_BIT_OFF_T || (defined __MINGW32__ && defined 
_FILE_OFFSET_BITS && (_FILE_OFFSET_BITS == 64))
   return _lseeki64 (fd, offset, whence);
 #else
   return lseek (fd, offset, whence);




reply via email to

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