Re: Audio File Library 0.2.4 released

 > On Sun, Sep 28, 2003 at 10:37:56AM +0200, Daniel Kobras wrote:
 > > On Fri, Sep 26, 2003 at 04:35:36AM -0500, Michael Pruett wrote:
 > > > Version 0.2.4 includes the following changes:
 > > > * Added support for large files.  This option is disabled by
 > > >   default; to enable large file support, run configure with the flag
 > > >   --enable-largefile.
 > >
 > > As far as I can tell, a largefile-enabled libaudiofile is binary
 > > incompatible to a standard one on systems where off_t defaults to 32bit.
 > > Shouldn't the SONAME be bumped in this case to avoid havoc?
 >
 > Daniel, that is correct.  I have merely verified that the library works
 > with large file support enabled and have added the option only so that
 > those who wish to use the library in this configuration can easily compile
 > it themselves.  I expect that the standard Linux distributions will not
 > use this option as it would break binary compatibility (and because the
 > vast majority of libraries in use today do not support large files).
 >

Which is a bad situation since media files can be very long, and some of
the libaudiofile clients are compiled in largefile mode. If you want to
see, run the test program from http://ac-archive.sf.net/largefile which
tells of mismatches.

The binary incompatibility on 64on32 systems (mostly linux and solaris)
arises from direct usage of off_t in header files, instead of using a
64bit type directly for the filesizes. That's the situation in libaudiofile
as well, see  grep off_t audiofile.h
   typedef off_t AFframecount;
   typedef off_t AFfileoffset;

It is however possible to write up an interfaces that allows the library
to be compiled in largefile mode itself and to offer function call entries
for _both_ 32bit off_t and 64bit off_t code. It needs a bunch of #ifdefs
and re-#defines in the header and wrappers for 32bit call entries in the
source code.

Probably, making up a dualmode library is nothing that a programmer
learns in school, and hopefully the 64on32 thing will get lost at some
point anyway. In the meantime, I did test with zziplib that it is
indeed possible to write up dualmode support in a straightforward
manner, in libaudiofile it would touch
$ egrep "AFframecount|AFfileoffset" *.h | wc -l
      15
api calls that would require a duplicate call entry for the other mode.

In other words, a dualmode library does not need to be renamed at all,
since it is the library that can serve both 32bit off_t clients and
64bit off_t clients at the same time - while being itself compiled in
largefile mode. The most wellknown dualmode library is libc, building
on the largefile capabilities of the kernel, and interestingly it just
works 

cheers,
-- guido                                  http://google.de/search?q=guidod
GCS/E/S/P C++/++++$ ULHS L++w- N++@ d(+-) s+a- r+@>+++ y++ 5++X- (geekcode)