[MPlayer-dev-eng] mingw32 large file support
Rich Felker
dalias at aerifal.cx
Sun Feb 12 05:21:00 CET 2006
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
More information about the MPlayer-dev-eng
mailing list