On Mon, 27 Apr 2020, Steve Lhomme wrote:
GetFileSize is not allowed.
Switching to GetFileSizeEx and SetFilePointerEx makes the types and comparison
cleaner.
Both API's are available in XP as the one they replace.
---
mingw-w64-crt/misc/mingw-fseek.c | 18 +++++++-----------
1 file changed, 7 insertions(+), 11 deletions(-)
diff --git a/mingw-w64-crt/misc/mingw-fseek.c b/mingw-w64-crt/misc/mingw-fseek.c
index 3ae7d856..c9f07305 100644
--- a/mingw-w64-crt/misc/mingw-fseek.c
+++ b/mingw-w64-crt/misc/mingw-fseek.c
@@ -39,30 +39,26 @@ __mingw_fwrite (const void *buffer, size_t size, size_t
count, FILE *fp)
# undef fwrite
if ((_osver & 0x8000) && __mingw_fseek_called)
Unrelated to this particular patch, but this seems to use _osver, which is
a data member exported by msvcrt.dll, but not available in UCRT. So even
if we fix this up, this particular object file wouldn't link successfully
with UCRT.
We could try to change headers to use a different accessor for _osver
(see e.g. 2e64b9e4537d564478f17b873b2f655f518325ed as example of that),
and provide some fallback for it in crt/ucrtbase_compat.c.
However... I don't see a single reference to __mingw_fwrite anywhere in
the source tree, same thing with __mingw_fseek. Is this expanded by some
macro somewhere, e.g. concatenating "__mingw_" with "fwrite"? Or is it the
case that this whole file is unreferenced by anything else and not
declared in headers? In that case I think we should be able to just delete
it outright.
// Martin
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
