[Mingw-w64-public] [Project News|New Builds]

2017-10-19 Thread niXman 

Hi,

The new builds of MinGW-W64 based on GCC-7.2.0 is uploaded, again =)
MinGW-w64 master branch is used.


32-bit:
posix-sjlj: 
https://sf.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/7.2.0/threads-posix/sjlj/i686-7.2.0-release-posix-sjlj-rt_v5-rev0.7z
(VirusTotal report: 
https://www.virustotal.com/#/file/817a4f525f794e4f340eee2f16bb5de249a2786e70917e07bca624ec92ca39ce/detection)


posix-dwarf: 
https://sf.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/7.2.0/threads-posix/dwarf/i686-7.2.0-release-posix-dwarf-rt_v5-rev0.7z
(VirusTotal report: 
https://www.virustotal.com/#/file/43beda83c9dffa72403ce9334b957bbe9efb15de8c8160a0a13eb8b96578c9e6/detection)


win32-sjlj: 
https://sf.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/7.2.0/threads-win32/sjlj/i686-7.2.0-release-win32-sjlj-rt_v5-rev0.7z
(VirusTotal report: 
https://www.virustotal.com/#/file/f00baeb96d20e70e6daa2cbc09d71c4855d134dc3eacf04bc8903af141268695/detection)


win32-dwarf: 
https://sf.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/7.2.0/threads-win32/dwarf/i686-7.2.0-release-win32-dwarf-rt_v5-rev0.7z
(VirusTotal report: 
https://www.virustotal.com/#/file/f407dc3549e275cfcd0f8941bdac64c25f2a62c949747d5e40fe0094499be59b/detection)



64-bit:
posix-sjlj: 
https://sf.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/7.2.0/threads-posix/sjlj/x86_64-7.2.0-release-posix-sjlj-rt_v5-rev0.7z
(VirusTotal report: 
https://www.virustotal.com/#/file/a5186624a5a41b550091c7cfec86198938ffbd8e198b81aaf99743dcc4a16f03/detection)


posix-seh: 
https://sf.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/7.2.0/threads-posix/seh/x86_64-7.2.0-release-posix-seh-rt_v5-rev0.7z
(VirusTotal report: 
https://www.virustotal.com/#/file/c43fe357f9cf7813178963c66e228ce9a43c0d1ab480c5b1b266da0d3c9eb22b/detection)


win32-sjlj: 
https://sf.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/7.2.0/threads-win32/sjlj/x86_64-7.2.0-release-win32-sjlj-rt_v5-rev0.7z
(VirusTotal report: 
https://www.virustotal.com/#/file/e427424111e54c79cadb77a1f950f3a3a9525217edf46b92eed4c4e29c65c50d/detection)


win32-seh: 
https://sf.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/7.2.0/threads-win32/seh/x86_64-7.2.0-release-win32-seh-rt_v5-rev0.7z
(VirusTotal report: 
https://www.virustotal.com/#/file/af7fc6863f335bb16f3dab994649ab92269bc3b4c62a7fd09628d5e1e4a84765/detection)




The online installer is also available:
https://sf.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/installer/mingw-w64-install.exe



--
Regards, niXman
___
Dual-target(32 & 64-bit) MinGW-W64 compilers for 32 and 64-bit Windows:
https://sf.net/p/mingw-w64/

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] _ftelli64 bug

2017-10-19 Thread Liu Hao 

On 2017/10/19 18:22, Mateusz Mikuła wrote:

You can try linking to different version of runtime library [0] like MSVC
does by default.

[0]
https://stackoverflow.com/questions/3402252/how-to-link-against-msvcr90-dll-with-mingw-gcc

MSVCR90 have been in the DLL hell for a decade so linking against it is 
not recommended. You can search for `MSVCR90.DLL` in your Windows 
directory and see how many incompatible copies of it exist. Linking 
against MSVCR90 will fail at run time without a proper .manifest file.


Also the answer on Stack Overflow is ineffective: After you build your 
program with `-lmsvcr100`, you will find the following hello-world 
program import `malloc()` from MSVCR100.DLL and `free()` from 
MSVCRT.DLL. This means some code in the executable allocates memory 
using the former, but deallocates it using the latter, which will result 
in memory corruption. At the moment, it is our `atexit()` function that 
is causing this problem, because being in one of the CRT startup files 
it follows any user-provided libraries (-lmsvcr100) but precedes 
hard-coded ones in the built-in specs of GCC (-lmsvcrt) in the final 
linker command line, and the order is significant.


If you are using an MSYS2 GCC, the CRT DLL can be overriden using the 
`-mcrtdll=msvcr100` option, otherwise you would have to dump, edit then 
re-import GCC's specs. These are the only ways to link against newer CRT 
DLLs safely.


```c
/* Try `gcc test.c -lmsvcr100` then take a look at
   the import table of the executable generated. */
#include 
#include 

void bark(void){
  puts("hello world!");
}
int main(void){
  atexit(bark);
}
```

--
Best regards,
LH_Mouse


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] _ftelli64 bug

2017-10-19 Thread Yuta Nakai 
Maybe this is a bug of MinGW-w64.
We have our own implementation of _ftelli64 for msvcrt.dll in libmingwex, 
because msvcrt.dll does not export it.

Workaround:
You can use ucrtbase.dll as C Runtime instead of msvcrt.dll.
Ucrtbase.dll exports _ftelli64.

Windows 10 版のメ�`ルから送信

差出人: Etienne Sandré-Chardonnal
送信日�r: 2017年10月19日 17:54
宛先: 
mingw-w64-public@lists.sourceforge.net
件名: Re: [Mingw-w64-public] _ftelli64 bug

Hi,

I don't think this is a text/binary issue:
 - I'm already opening with "rb"
 - This is random
 - This only happens when doing concurrent reads
 - ftell works while _ftelli64 has problems

To me this is a race condition in _ftelli64

I have tested the code in MSVC 2015, and the bug is not there.

Etienne

2017-10-19 10:36 GMT+02:00 Kai Tietz via Mingw-w64-public <
mingw-w64-public@lists.sourceforge.net>:

> Hello,
>
> I am not quite sure if this is a Windows bug.  The API you are using
> is actually that one from msvcrt.dll for large/none-large file
> accesses.
> The most common issue showing this behavior is the TEXT vs. BINARY
> file open mode on Windows C-runtime.  New-lines might be expanded to
> carriage-return + new-line, which can change possitions easily.  To
> avoid that use on file open the additional flag O_BINARY.
>
> Regards, and I hope this will help you,
> Kai
>
> 2017-10-19 10:06 GMT+02:00 Etienne Sandré-Chardonnal <
> etienne.san...@m4x.org>:
> > Dear all,
> >
> > I have a program which reads concurrently multiple files using the C I/O
> > library. I have encountered  a problem, _ftelli64 randomly reports an
> > incorrect position, with a mismatch of a few bytes. The bug disappears if
> > any of these changes is done:
> >
> >- ftell is used instead of _ftelli64 (but no more large file support)
> >- std::ifstream is used instead of C functions (but I need _wfopen for
> >unicode file names)
> >- files are not read concurrently (reading threads set to 1)
> >
> > I have reproduced this in the attached MCVE. It does create 8 files
> > approximately 3MB large, and reads them concurrently in 8 threads by
> 65544
> > byte blocks. It compares the value returned by fread() and the difference
> > between _ftelli64 calls before and after fread(). It prints the
> mismatches.
> >
> > Typical output is :
> >
> > Error 2.dat / ftell before 3080570 / fread returned 65544 / ftell after
> > 3146112 / mismatch -2
> >
> > Error 6.dat / ftell before 3080569 / fread returned 65544 / ftell after
> > 3146112 / mismatch -1
> >
> > Error 4.dat / ftell before 65544 / fread returned 65544 / ftell after
> > 131089 / mismatch 1
> >
> > Error 5.dat / ftell before 0 / fread returned 65544 / ftell after 65543 /
> > mismatch -1
> >
> > Error 5.dat / ftell before 65543 / fread returned 65544 / ftell after
> > 131088 / mismatch 1
> >
> > Error 4.dat / ftell before 2162953 / fread returned 65544 / ftell after
> > 2228498 / mismatch 1
> >
> > Error 5.dat / ftell before 2162952 / fread returned 65544 / ftell after
> > 2228497 / mismatch 1
> >
> > Error 4.dat / ftell before 3080570 / fread returned 65544 / ftell after
> > 3146112 / mismatch -2
> >
> > Error 5.dat / ftell before 3080569 / fread returned 65544 / ftell after
> > 3146112 / mismatch -1
> >
> >
> > Is this a bug from windows or from MinGW C library?
> >
> > Thanks!
> > 
> --
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > ___
> > Mingw-w64-public mailing list
> > Mingw-w64-public@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net

Re: [Mingw-w64-public] _ftelli64 bug

2017-10-19 Thread Mateusz Mikuła 
You can try linking to different version of runtime library [0] like MSVC
does by default.

[0]
https://stackoverflow.com/questions/3402252/how-to-link-against-msvcr90-dll-with-mingw-gcc

2017-10-19 10:54 GMT+02:00 Etienne Sandré-Chardonnal :

> Hi,
>
> I don't think this is a text/binary issue:
>  - I'm already opening with "rb"
>  - This is random
>  - This only happens when doing concurrent reads
>  - ftell works while _ftelli64 has problems
>
> To me this is a race condition in _ftelli64
>
> I have tested the code in MSVC 2015, and the bug is not there.
>
> Etienne
>
> 2017-10-19 10:36 GMT+02:00 Kai Tietz via Mingw-w64-public <
> mingw-w64-public@lists.sourceforge.net>:
>
> > Hello,
> >
> > I am not quite sure if this is a Windows bug.  The API you are using
> > is actually that one from msvcrt.dll for large/none-large file
> > accesses.
> > The most common issue showing this behavior is the TEXT vs. BINARY
> > file open mode on Windows C-runtime.  New-lines might be expanded to
> > carriage-return + new-line, which can change possitions easily.  To
> > avoid that use on file open the additional flag O_BINARY.
> >
> > Regards, and I hope this will help you,
> > Kai
> >
> > 2017-10-19 10:06 GMT+02:00 Etienne Sandré-Chardonnal <
> > etienne.san...@m4x.org>:
> > > Dear all,
> > >
> > > I have a program which reads concurrently multiple files using the C
> I/O
> > > library. I have encountered  a problem, _ftelli64 randomly reports an
> > > incorrect position, with a mismatch of a few bytes. The bug disappears
> if
> > > any of these changes is done:
> > >
> > >- ftell is used instead of _ftelli64 (but no more large file
> support)
> > >- std::ifstream is used instead of C functions (but I need _wfopen
> for
> > >unicode file names)
> > >- files are not read concurrently (reading threads set to 1)
> > >
> > > I have reproduced this in the attached MCVE. It does create 8 files
> > > approximately 3MB large, and reads them concurrently in 8 threads by
> > 65544
> > > byte blocks. It compares the value returned by fread() and the
> difference
> > > between _ftelli64 calls before and after fread(). It prints the
> > mismatches.
> > >
> > > Typical output is :
> > >
> > > Error 2.dat / ftell before 3080570 / fread returned 65544 / ftell after
> > > 3146112 / mismatch -2
> > >
> > > Error 6.dat / ftell before 3080569 / fread returned 65544 / ftell after
> > > 3146112 / mismatch -1
> > >
> > > Error 4.dat / ftell before 65544 / fread returned 65544 / ftell after
> > > 131089 / mismatch 1
> > >
> > > Error 5.dat / ftell before 0 / fread returned 65544 / ftell after
> 65543 /
> > > mismatch -1
> > >
> > > Error 5.dat / ftell before 65543 / fread returned 65544 / ftell after
> > > 131088 / mismatch 1
> > >
> > > Error 4.dat / ftell before 2162953 / fread returned 65544 / ftell after
> > > 2228498 / mismatch 1
> > >
> > > Error 5.dat / ftell before 2162952 / fread returned 65544 / ftell after
> > > 2228497 / mismatch 1
> > >
> > > Error 4.dat / ftell before 3080570 / fread returned 65544 / ftell after
> > > 3146112 / mismatch -2
> > >
> > > Error 5.dat / ftell before 3080569 / fread returned 65544 / ftell after
> > > 3146112 / mismatch -1
> > >
> > >
> > > Is this a bug from windows or from MinGW C library?
> > >
> > > Thanks!
> > > 
> > --
> > > Check out the vibrant tech community on one of the world's most
> > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > > ___
> > > Mingw-w64-public mailing list
> > > Mingw-w64-public@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
> >
> > 
> > --
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > ___
> > Mingw-w64-public mailing list
> > Mingw-w64-public@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
> >
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] _ftelli64 bug

2017-10-19 Thread Etienne Sandré-Chardonnal 
Hi,

I don't think this is a text/binary issue:
 - I'm already opening with "rb"
 - This is random
 - This only happens when doing concurrent reads
 - ftell works while _ftelli64 has problems

To me this is a race condition in _ftelli64

I have tested the code in MSVC 2015, and the bug is not there.

Etienne

2017-10-19 10:36 GMT+02:00 Kai Tietz via Mingw-w64-public <
mingw-w64-public@lists.sourceforge.net>:

> Hello,
>
> I am not quite sure if this is a Windows bug.  The API you are using
> is actually that one from msvcrt.dll for large/none-large file
> accesses.
> The most common issue showing this behavior is the TEXT vs. BINARY
> file open mode on Windows C-runtime.  New-lines might be expanded to
> carriage-return + new-line, which can change possitions easily.  To
> avoid that use on file open the additional flag O_BINARY.
>
> Regards, and I hope this will help you,
> Kai
>
> 2017-10-19 10:06 GMT+02:00 Etienne Sandré-Chardonnal <
> etienne.san...@m4x.org>:
> > Dear all,
> >
> > I have a program which reads concurrently multiple files using the C I/O
> > library. I have encountered  a problem, _ftelli64 randomly reports an
> > incorrect position, with a mismatch of a few bytes. The bug disappears if
> > any of these changes is done:
> >
> >- ftell is used instead of _ftelli64 (but no more large file support)
> >- std::ifstream is used instead of C functions (but I need _wfopen for
> >unicode file names)
> >- files are not read concurrently (reading threads set to 1)
> >
> > I have reproduced this in the attached MCVE. It does create 8 files
> > approximately 3MB large, and reads them concurrently in 8 threads by
> 65544
> > byte blocks. It compares the value returned by fread() and the difference
> > between _ftelli64 calls before and after fread(). It prints the
> mismatches.
> >
> > Typical output is :
> >
> > Error 2.dat / ftell before 3080570 / fread returned 65544 / ftell after
> > 3146112 / mismatch -2
> >
> > Error 6.dat / ftell before 3080569 / fread returned 65544 / ftell after
> > 3146112 / mismatch -1
> >
> > Error 4.dat / ftell before 65544 / fread returned 65544 / ftell after
> > 131089 / mismatch 1
> >
> > Error 5.dat / ftell before 0 / fread returned 65544 / ftell after 65543 /
> > mismatch -1
> >
> > Error 5.dat / ftell before 65543 / fread returned 65544 / ftell after
> > 131088 / mismatch 1
> >
> > Error 4.dat / ftell before 2162953 / fread returned 65544 / ftell after
> > 2228498 / mismatch 1
> >
> > Error 5.dat / ftell before 2162952 / fread returned 65544 / ftell after
> > 2228497 / mismatch 1
> >
> > Error 4.dat / ftell before 3080570 / fread returned 65544 / ftell after
> > 3146112 / mismatch -2
> >
> > Error 5.dat / ftell before 3080569 / fread returned 65544 / ftell after
> > 3146112 / mismatch -1
> >
> >
> > Is this a bug from windows or from MinGW C library?
> >
> > Thanks!
> > 
> --
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > ___
> > Mingw-w64-public mailing list
> > Mingw-w64-public@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] _ftelli64 bug

2017-10-19 Thread Kai Tietz via Mingw-w64-public 
Hello,

I am not quite sure if this is a Windows bug.  The API you are using
is actually that one from msvcrt.dll for large/none-large file
accesses.
The most common issue showing this behavior is the TEXT vs. BINARY
file open mode on Windows C-runtime.  New-lines might be expanded to
carriage-return + new-line, which can change possitions easily.  To
avoid that use on file open the additional flag O_BINARY.

Regards, and I hope this will help you,
Kai

2017-10-19 10:06 GMT+02:00 Etienne Sandré-Chardonnal :
> Dear all,
>
> I have a program which reads concurrently multiple files using the C I/O
> library. I have encountered  a problem, _ftelli64 randomly reports an
> incorrect position, with a mismatch of a few bytes. The bug disappears if
> any of these changes is done:
>
>- ftell is used instead of _ftelli64 (but no more large file support)
>- std::ifstream is used instead of C functions (but I need _wfopen for
>unicode file names)
>- files are not read concurrently (reading threads set to 1)
>
> I have reproduced this in the attached MCVE. It does create 8 files
> approximately 3MB large, and reads them concurrently in 8 threads by 65544
> byte blocks. It compares the value returned by fread() and the difference
> between _ftelli64 calls before and after fread(). It prints the mismatches.
>
> Typical output is :
>
> Error 2.dat / ftell before 3080570 / fread returned 65544 / ftell after
> 3146112 / mismatch -2
>
> Error 6.dat / ftell before 3080569 / fread returned 65544 / ftell after
> 3146112 / mismatch -1
>
> Error 4.dat / ftell before 65544 / fread returned 65544 / ftell after
> 131089 / mismatch 1
>
> Error 5.dat / ftell before 0 / fread returned 65544 / ftell after 65543 /
> mismatch -1
>
> Error 5.dat / ftell before 65543 / fread returned 65544 / ftell after
> 131088 / mismatch 1
>
> Error 4.dat / ftell before 2162953 / fread returned 65544 / ftell after
> 2228498 / mismatch 1
>
> Error 5.dat / ftell before 2162952 / fread returned 65544 / ftell after
> 2228497 / mismatch 1
>
> Error 4.dat / ftell before 3080570 / fread returned 65544 / ftell after
> 3146112 / mismatch -2
>
> Error 5.dat / ftell before 3080569 / fread returned 65544 / ftell after
> 3146112 / mismatch -1
>
>
> Is this a bug from windows or from MinGW C library?
>
> Thanks!
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] _ftelli64 bug

2017-10-19 Thread Etienne Sandré-Chardonnal 
Dear all,

I have a program which reads concurrently multiple files using the C I/O
library. I have encountered  a problem, _ftelli64 randomly reports an
incorrect position, with a mismatch of a few bytes. The bug disappears if
any of these changes is done:

   - ftell is used instead of _ftelli64 (but no more large file support)
   - std::ifstream is used instead of C functions (but I need _wfopen for
   unicode file names)
   - files are not read concurrently (reading threads set to 1)

I have reproduced this in the attached MCVE. It does create 8 files
approximately 3MB large, and reads them concurrently in 8 threads by 65544
byte blocks. It compares the value returned by fread() and the difference
between _ftelli64 calls before and after fread(). It prints the mismatches.

Typical output is :

Error 2.dat / ftell before 3080570 / fread returned 65544 / ftell after
3146112 / mismatch -2

Error 6.dat / ftell before 3080569 / fread returned 65544 / ftell after
3146112 / mismatch -1

Error 4.dat / ftell before 65544 / fread returned 65544 / ftell after
131089 / mismatch 1

Error 5.dat / ftell before 0 / fread returned 65544 / ftell after 65543 /
mismatch -1

Error 5.dat / ftell before 65543 / fread returned 65544 / ftell after
131088 / mismatch 1

Error 4.dat / ftell before 2162953 / fread returned 65544 / ftell after
2228498 / mismatch 1

Error 5.dat / ftell before 2162952 / fread returned 65544 / ftell after
2228497 / mismatch 1

Error 4.dat / ftell before 3080570 / fread returned 65544 / ftell after
3146112 / mismatch -2

Error 5.dat / ftell before 3080569 / fread returned 65544 / ftell after
3146112 / mismatch -1


Is this a bug from windows or from MinGW C library?

Thanks!
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public