[MPlayer-dev-eng] mingw32 large file support

[Joey Parrish]

On Sat, Feb 11, 2006 at 11:21:00PM -0500, Rich Felker wrote:
> 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:
> > > 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.

Yes, I understand.  I just wanted to explain that the decision was not
without reason.  My priority was not accidentally using 32-bit types in
the project I was creating it for.  But for MPlayer, I'd be happy to
write it the other way.

--Joey

-- 
"That is just splendid, dandy, rad, and cool," said the Salesman, and
  he quickly started unloading a Pizza Restaurant from his Cargo Bay.