I see no problem adding "defined(__sgi)" to the list of conditions
for using "unsigned long long" in unzpriv.h.
+# ifndef __sgi
+# define _LARGEFILE_SOURCE /* some OSes need this for fseeko */
+# define _LARGEFILE64_SOURCE
+# endif
Does defining these macros cause actual harm on IRIX? (If so, what?)
We define them on many systems where they're not needed/used. If they
are simply unnecessary (but not harmful), then I'd rather not add a
condition. But, if they really cause a problem, then we could do it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A little more research led to a few more thoughts.
To recognize an SGI IRIX system, we seem to be using an old-style
macro, "sgi", not the more modern "__sgi". I assume that both work on
modern systems, but plain "sgi" might work better on very old systems,
so we would probably stick with plain "sgi".
which suggest that what we really want for large-file support would be
fseek64(), ftell64(), and so on, not the more typical fseeko(),
ftello(), and so on. There seems to be an "off64_t" type, too, used by
lseek64(). I don't see anything in our code to accommodate these
(SGI-IRIX-specific?) functions/types, so I'd guess that we don't really
have large-file support on these systems. I'd be willing to spend some
time to make some changes to get this working, but only if I could get
access to a real IRIX system on which to do some testing. Otherwise, if
someone else who has such access could supply some harmless-looking
patches, then we'd probably be willing to apply them.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
patch for irix support
Thanks for the report and the suggestions.
I see no problem adding "defined(__sgi)" to the list of conditions
for using "unsigned long long" in unzpriv.h.
+# ifndef __sgi
+# define _LARGEFILE_SOURCE /* some OSes need this for fseeko */
+# define _LARGEFILE64_SOURCE
+# endif
Does defining these macros cause actual harm on IRIX? (If so, what?)
We define them on many systems where they're not needed/used. If they
are simply unnecessary (but not harmful), then I'd rather not add a
condition. But, if they really cause a problem, then we could do it.
A little more research led to a few more thoughts.
To recognize an SGI IRIX system, we seem to be using an old-style
macro, "sgi", not the more modern "__sgi". I assume that both work on
modern systems, but plain "sgi" might work better on very old systems,
so we would probably stick with plain "sgi".
According to:
http://www.sgi.com/services/support/irix_mips_support.html
the number of people who care may be getting pretty small.
I found these "man" pages:
http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=0650&db=man&fname=/usr/share/catman/p_man/cat3s/fseek.z
http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=0650&db=man&fname=/usr/share/catman/p_man/cat2/standard/lseek.z
which suggest that what we really want for large-file support would be
fseek64(), ftell64(), and so on, not the more typical fseeko(),
ftello(), and so on. There seems to be an "off64_t" type, too, used by
lseek64(). I don't see anything in our code to accommodate these
(SGI-IRIX-specific?) functions/types, so I'd guess that we don't really
have large-file support on these systems. I'd be willing to spend some
time to make some changes to get this working, but only if I could get
access to a real IRIX system on which to do some testing. Otherwise, if
someone else who has such access could supply some harmless-looking
patches, then we'd probably be willing to apply them.