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

[Pete Batard]

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