[MPlayer-dev-eng] mingw32 large file support

[Rich Felker]

On Sat, Feb 11, 2006 at 10:50:10AM -0600, Joey Parrish wrote:
> 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.  :)

Well I'm against using the hack api as the unified api. The unified
api should be the standard posix api, and systems that are broken
should have well-hidden workarounds. This goes with my fundamental
principle of workarounds:

  The workaround must always be placed as close as possible to the
  broken component that it's working around, and should be totally
  invisible to non-broken components.

Or something like that. It was discussed in a past thread.

Rich