[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
detected.
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.
Regards,
/Pete