[Top][All Lists]

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

[Libcdio-help] Large file support and binary compatibility on 32 bit sys

From: Bastiaan Timmer
Subject: [Libcdio-help] Large file support and binary compatibility on 32 bit systems
Date: Thu, 7 Jul 2011 02:43:26 -0700 (PDT)

Hi! I've been writing a CD ripping utility under linux using libcdio. At first, 
I only allowed ripping whole discs, but I have just added functionality to rip 
separate tracks as well. When testing this new option I found that seeking to a 
frame (using 'cdio_paranoia_seek(cdrom_paranoia_t *, off_t, int)') would always 
fail, and fail silently. It took me quite a while to figure out what the 
problem was.

As it turns out, libcdio on my system (I just installed it from Fedora's 
software repository) is compiled with large file support, which sets the 
_FILE_OFFSET_BITS symbol to 64. This causes the off_t type in the library 
(which is used in cdio_paranoia_seek) to be 8 bytes. On 32-bit systems, like 
mine, an off_t is usually only 4 bytes. When calling the function from my code, 
it was called with a 4 byte off_t and a 4 byte int as 2nd and 3rd arguments. 
The library however, would take both the off_t and the int as the 8 byte off_t 
it expects, and use some garbage value for the last int. Some very small 
example code showing this exact problem can be found here:

Now, currently I am simply compiling my program with -D_FILE_OFFSET_BITS=64 to 
force a 64 bit off_t in my program as well, which fixes the problem. But if I 
were to distribute my program, how would users know how to compile? If I simply 
set _FILE_OFFSET_BITS=64 then they will get similar problems if their 
distributions package maintainers happen to have compiled libcdio without large 
file support. Does the library have any way of letting users know how large it 
thinks an off_t is?

Also, if a program would need to link to several different 3rd party libraries, 
some requiring _FILE_OFFSET_BITS to be set to 32 and others to 64, even letting 
users know how it was compiled will not help. Perhaps the best thing to do is 
to leave _FILE_OFFSET_BITS at the system default value (32 bit on x86, 64 on 
x86_64), and do what fseek/fseek64 and lseek/lseek64 do. That is, if the system 
has 32 bit architecture and large file support is enabled, then make a function 
'cdio_paranoia_seek64(cdrom_paranoia_t *, off64_t, int)' available (see also 
the manpage of lseek64).

By the way, is the cdio_paranoia_seek function ever used for things other than 
audio CD's? Because if not, why would it ever need a 64 bit file offset type 
anyway, neither in frames nor even in bytes will a 32 bit value be to small to 
address a CD, right?

Bas Timmer

reply via email to

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