On 2025-12-15 1:12 p.m., Matthias Klose wrote: > On 12/14/25 23:26, John David Anglin wrote: >> Package: autoconf2.69 >> Version: 2.69-3.1 >> Severity: normal >> X-Debbugs-Cc: [email protected] >> User: [email protected] >> Usertags: hppa >> >> Dear Maintainer, >> >> See buildbot output: >> >> >> Whether or not generated configure file is correct, it's inconsistent with >> output generated by vanilla autoconf version 2.69 and it triggers buildbot >> failures. > > that is > debian/patches/avoid-undefined-behavior-for-32bit-off_t.patch: > > the patch is also in Debian's autoconf (2.72) package, apparently never > forwarded. > > > Description: Fix undefined behavior for 32-bit off_t. > autoconf (2.69-6) unstable; urgency=low > . > * lib/autoconf/specific.m4: Use ((off_t) 1 << 31) << 31 in place of > (off_t) 1 << 62 to avoid undefined behavior when off_t is 32-bit. > Closes: #742780. Thanks to Mathieu Malaterre <[email protected]> for > reporting this bug. > Author: Ben Pfaff <[email protected]> > Bug-Debian: http://bugs.debian.org/742780 > Forwarded: yes > > --- > Bug: #742780. > Bug-Debian: http://bugs.debian.org/742780 > Last-Update: 2014-03-27 > > --- autoconf-2.69.orig/lib/autoconf/specific.m4 > +++ autoconf-2.69/lib/autoconf/specific.m4 > @@ -92,7 +92,7 @@ m4_define([_AC_SYS_LARGEFILE_TEST_INCLUD > We can't simply define LARGE_OFF_T to be 9223372036854775807, > since some C++ compilers masquerading as C compilers > incorrectly reject 9223372036854775807. */ > -@%:@define LARGE_OFF_T (((off_t) 1 << 62) - 1 + ((off_t) 1 << 62)) > +@%:@define LARGE_OFF_T ((((off_t) 1 << 31) << 31) - 1 + (((off_t) 1 << 31) > << 31)) > int off_t_is_large[[(LARGE_OFF_T % 2147483629 == 721 > && LARGE_OFF_T % 2147483647 == 1) > ? 1 : -1]];[]dnl Don't all Debian architectures now use 64-bit offsets (_FILE_OFFSET_BITS == 64). In features.h, we have:
#if defined _FILE_OFFSET_BITS && _FILE_OFFSET_BITS == 64 # define __USE_FILE_OFFSET64 1 #endif So, maybe the above patch can now be dropped. Some patch also adds two free() statements. Dave -- John David Anglin [email protected]
