[Bug libfortran/42420] libgfortran fails to open large files on MINGW32

["jb at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #6 from jb at gcc dot gnu dot org  2009-12-20 10:23 -------
As such the patch seems ok, however I'd prefer to avoid cluttering up the logic
with ifdefs, and secondly, we should stick to one kind of stat struct
everywhere for consistency's sake. E.g. something like

diff --git a/libgfortran/io/unix.c b/libgfortran/io/unix.c
index 07aa4d9..531f6ec 100644
--- a/libgfortran/io/unix.c
+++ b/libgfortran/io/unix.c
@@ -42,13 +42,17 @@ see the files COPYING3 and COPYING.RUNTIME respectively. 
If

 /* For mingw, we don't identify files by their inode number, but by a
    64-bit identifier created from a BY_HANDLE_FILE_INFORMATION. */
-#if defined(__MINGW32__) && !HAVE_WORKING_STAT
+#ifdef __MINGW32__

 #define WIN32_LEAN_AND_MEAN
 #include <windows.h>

 #define lseek _lseeki64
+#define fstat _fstati64
+#define stat _stati64
+typedef struct _stati64 gfstat_t

+#ifndef HAVE_WORKING_STAT
 static uint64_t
 id_from_handle (HANDLE hFile)
 {
@@ -91,6 +95,9 @@ id_from_fd (const int fd)
 }

 #endif
+#else
+typedef struct stat gfstat_t
+#endif

 #ifndef PATH_MAX
 #define PATH_MAX 1024
@@ -781,7 +788,7 @@ open_internal (char *base, int length, gfc_offset offset)
 static stream *
 fd_to_stream (int fd, int prot)
 {
-  struct stat statbuf;
+  gfstat_t statbuf;
   unix_stream *s;

   s = get_mem (sizeof (unix_stream));
@@ -1220,9 +1227,9 @@ int
 compare_file_filename (gfc_unit *u, const char *name, int len)
 {
   char path[PATH_MAX + 1];
-  struct stat st1;
+  gfstat_t st1;
 #ifdef HAVE_WORKING_STAT
-  struct stat st2;
+  gfstat_t st2;
 #else
 # ifdef __MINGW32__
   uint64_t id1, id2;
@@ -1261,7 +1268,7 @@ compare_file_filename (gfc_unit *u, const char *name, int 


 #ifdef HAVE_WORKING_STAT
-# define FIND_FILE0_DECL struct stat *st
+# define FIND_FILE0_DECL gfstat_t *st
 # define FIND_FILE0_ARGS st
 #else
 # define FIND_FILE0_DECL uint64_t id, const char *file, gfc_charlen_type
file_l
@@ -1318,7 +1325,7 @@ gfc_unit *
 find_file (const char *file, gfc_charlen_type file_len)
 {
   char path[PATH_MAX + 1];
-  struct stat st[2];
+  gfstat_t st[2];
   gfc_unit *u;
 #if defined(__MINGW32__) && !HAVE_WORKING_STAT
   uint64_t id = 0ULL;
@@ -1455,7 +1462,7 @@ int
 file_exists (const char *file, gfc_charlen_type file_len)
 {
   char path[PATH_MAX + 1];
-  struct stat statbuf;
+  gfstat_t statbuf;

   if (unpack_filename (path, file, file_len))
     return 0;
@@ -1478,7 +1485,7 @@ const char *
 inquire_sequential (const char *string, int len)
 {
   char path[PATH_MAX + 1];
-  struct stat statbuf;
+  gfstat_t statbuf;

   if (string == NULL ||
       unpack_filename (path, string, len) || stat (path, &statbuf) < 0)
@@ -1502,7 +1509,7 @@ const char *
 inquire_direct (const char *string, int len)
 {
   char path[PATH_MAX + 1];
-  struct stat statbuf;
+  gfstat_t statbuf;

   if (string == NULL ||
       unpack_filename (path, string, len) || stat (path, &statbuf) < 0)
@@ -1526,7 +1533,7 @@ const char *
 inquire_formatted (const char *string, int len)
 {
   char path[PATH_MAX + 1];
-  struct stat statbuf;
+  gfstat_t statbuf;

   if (string == NULL ||
       unpack_filename (path, string, len) || stat (path, &statbuf) < 0)


This is completely untested.

And, as a general observation, if mingw is ever going to be a tier-1 target for
gfortran, we need one or more maintainers who use and care about gfortran on
windows. So far all the maintainers are, to the best of my knowledge, Linux or
FreeBSD users, and any mingw support is, at best, an afterthought. Same goes
for OS X, FWIW.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42420