Am Sun, 21 Jun 2020 11:23:32 +0200
schrieb Sebastian Ramacher <sramacher@debian.org>:
> I am wondering why syn123 and mpg123 use different approaches to achieve
> the same thing. The mpg123-way of handling off_t using functions is
> known to work and doesn't require any quirks on the Debian packaging
> side. Why doesn't syn123 also use MPG123_LARGENAME?
Well, then. I need to dive into this myself, again. First: syn123 is
using the same approach as MPG123_LARGENAME, actually. It is just
avoiding the flexible macro machinery to cover only two functions that
are affected. But the basic behaviour is the same
- _FILE_OFFSET_BITS==32: foo123_func → foo123_func_32
- _FILE_OFFSET_BITS==64: foo123_func → foo123_func_64
A difference is in how the libraries are built. In libmpg123, I used
off_t in the library, and it appeared in the API for a while, without
dealing with the issues of possible mismatch in large file support in
lib and client applications. There was a very painful transition to
make libmpg123 offer both LFS settings in one library like glibc does.
This resulted in warts like
src/libmpg123/lfs_alias.c
src/libmpg123/lfs_wrap.c
for the need to sport foo123_func, foo123_func_32, and foo123_func_64
in the same library (any of those can be an alias or wrapper, depening
on mpg123 build setup), to be compatible with all user binaries.
For syn123, off_t entered late in the game and there' actually no I/O
involved. It's just about function argument types. I decided to
simplify things by hardcoding _32 and _64 variants and having the
header decide at compile time which one is used.
The case of no _FILE_OFFSET_BITS being defined, in lack of a generic
suffix-less function for that case, results in the value LFS_ALIAS_BITS
being used. This results from this configure code:
dnl The native type used for aliases is what off_t maps to without any largefile-
dnl enabling switches. So, it's long int if the system is largefile-senstive,
dnl but it is actual plain off_t if the system does not have such switches.
if test "x$largefile_sensitive" = xyes; then
lfs_alias_type=long
lfs_alias_size=$ac_cv_sizeof_long
elif test "x$android_build" = xyes; then
lfs_alias_type=off64_t
lfs_alias_size=$ac_cv_sizeof_off64_t
else
lfs_alias_type=off_t
lfs_alias_size=$ac_cv_sizeof_off_t
fi
if test "x$lfs_alias_size" = "x"; then
AC_MSG_ERROR([Cannot determine sizeof(lfs_alias_t)?])
else
LFS_ALIAS_BITS=`expr "$lfs_alias_size" "*" "8"`
AC_DEFINE_UNQUOTED([lfs_alias_t], $lfs_alias_type,
[Define to the native offset type (long or actually off_t).])
AC_DEFINE_UNQUOTED([LFS_ALIAS_BITS], $LFS_ALIAS_BITS,
[Define this to the size of native offset type in bits, used for LFS alias functions.])
fi
If we can get that logic into the header itself, it would be
arch-agnostic again. Is that easy enough? Otherwise, I'd have to add
plain wrappers named syn123_resample_total and syn123_resample_intotal,
like:
lfs_alias_t syn123_resample_total(long inrate, long outrate, lfs_alias_t ins)
{
#if LFS_ALIAS_BITS+0 == 64
return syn123_resample_total_64(inrate, outrate, ins);
#elif LFS_ALIAS_BITS+0 == 32
return syn123_resample_total_32(inrate, outrate, ins);
#else
#error "Unexpected LFS_ALIAS_BITS value."
#endif
}
lfs_alias_t syn123_resample_intotal(long inrate, long outrate, lfs_alias_t outs)
{
#if LFS_ALIAS_BITS+0 == 64
return syn123_resample_intotal_64(inrate, outrate, outs);
#elif LFS_ALIAS_BITS+0 == 32
return syn123_resample_intotal_32(inrate, outrate, outs);
#else
#error "Unexpected LFS_ALIAS_BITS value."
#endif
}
It's all ugly crap that we could avoid if we'd only settle for LFS
support being a fixed property of an architecture/OS setup, off_t not
being a chimera depending on a preprocessor switch.
Do you have a suggestion to avoid using @LFS_ALIAS_BITS@ in the header
and still keep the correct logic catering for the cases for choosing
lfs_alias_t?
If not, I guess I could add these two wrappers and forget about them,
as the code in question won't change much and I don't intend to add
more LFS-aware functions to syn123.
But I really was burned by what I had to do for libmpg123 and did not
want to repeat all that cruft.
Alrighty then,
Thomas
Attachment:
pgpYDplAEXa1W.pgp
Description: Firma digital OpenPGP