[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Libcdio-devel] [PATCH] Non LFS dependent fseeko detection and off_t

From: Pete Batard
Subject: Re: [Libcdio-devel] [PATCH] Non LFS dependent fseeko detection and off_t truncation checks
Date: Wed, 25 Jan 2012 16:12:20 +0000
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1

On 2012.01.25 03:53, Rocky Bernstein wrote:
- adding fseeko detection that doesn't rely on LFS
- detecting truncation of off_t when LFS is in use but fseeko was not

While all of this is good, the two thoughts.

First figuring out what is wrong with HAVE_FSEEKO so that can be reported
back to the autoconf folks. (That said, I haven't had much luck in getting
changes back).

Time permitting, I'll try to do that. That ARM platform should definitely have detected it.

Second, as alluded to previously, should there be a --enable/--disable
configure switch to try to force one way or another?

Well, I'd rather stick with a wait and see approach on this for the time being.

Overall, I'd like to encourage the use of fseeko whenever possible, because, really, using an fseek that only takes a long in this day an age is asking for trouble. Thus, if not providing a configure option to disable fseeko results in libcdio users investing a little time checking the LFS behaviour of their app, and possibly improving on it, before they contact the list, it may not be a bad thing.

Also, fseeko is not actually tied to LFS. If you don't define FILE_OFFSET_BITS, fseeko is 32 bit on 32 bit platforms and perfectly interchangeable with fseek. We don't really offer options to individually disable calls such bzero, snprintf, etc, when we find we can use them, so I think ftello should probably be the same.

As to LFS, in all, AC_SYS_LARGEFILE does provide a --disable-largefile to configure, which should continue to work.

Finally, MinGW is likely to reshuffle things further. Not in terms of changes for other platforms, but because LFS handling is going to be a different ballgame. MSVC support may have an impact as well, though it doesn't rely on configure (will have to use a separate, manually edited config header).

On the subject of MinGW, since this is where I'm headed next, here's an outline of what I plan to do. The main problem we are faced with there is that off_t, which is picked up from sys/types.h, is defined as a long always (at least with MinGW32). There's no support whatsoever for an off_t that can be 64 bit (there is a 64 bit off64_t defined, but it's separate) which means that all the off_t calls we use expect a 32 bit value at all time on MinGW32.

The workaround I used, in the libcdio source I modified for my app, was to switch to using off64_t everywhere, as well as explicitly use the 64 bit variants of fseek, etc, that are also available.

Obviously, forcing off64_t always in mainline libcdio won't fly and will break LFS on Linux, etc.. What I'm planning to do then, is undefine HAVE_SYS_TYPES_H for MinGW and use a custom type.h header that defines off_t to 64 bit. Once we have that, it should be possible to sort the calls that needs to be modified for 64 off_t and this approach can also be used to enable LFS support on platforms that don't use _FILE_OFFSET_BITS, but that have 64 bit variants of file I/O, such as MSVC...

Anyway, I'll have more on that when I have a patch to submit.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]