[MPlayer-dev-eng] mingw32 large file support

[Joey Parrish]

On Thu, Jan 26, 2006 at 06:04:19PM -0500, Rich Felker wrote:
> On Thu, Jan 26, 2006 at 09:42:21AM -0600, Joey Parrish wrote:
> > Attached is all64.h, a header to merge the different 64-bit file APIs on
> > MinGW, Cygwin, and Linux.  Be sure to include it before any other file.
> > 
> > Also attached is a test app to allow you to quickly test all64 and make
> > sure it works as expected.  I've tested it on all three platforms.
> > 
> > Is this helpful?
> 
> Yes, however I'm strongly against this part:
> 
> /*
>  * Now use these:
>  *  struct stat64
>  *  stat64()
>  *  fstat64()
>  *  lstat64()
>  *  off64_t
>  *  open64()
>  *  lseek64()
>  *  fpos64_t
>  *  fopen64()
>  *  fdopen64()
>  *  ftello64()
>  *  fseeko64()
>  *  fgetpos64()
>  *  fsetpos64()
>  *  tmpfile64()
>  */
> 
> Instead your header should use the preprocessor to replace the broken
> 32bit versions with 64bit ones. If applications directly use these
> stupid *64 interfaces, they're not remotely portable and will not work
> on non-stupid implementations where file offsets are always 64bit
> (like my new replacement libc :).

I see what you mean.  My reasoning was this:  One of two things will be
true on any platform.  If have a def for things like stat64, then you'll
have no problems.  If you don't have these defs, then you'd get a
compilation error if you forget to include all64.h.  That seemed like a
good way to make sure I didn't accidentally forget to use it.  I didn't
want to spend hours trying to figure out why things were screwy.

But, yes, ideally we would all use normal calls and get 64-bit types
automatically.  On the other hand, ideally, we wouldn't need this header
to get a unified API, either.  :)

--Joey

-- 
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams