• Bug#1066952: Defaulting to -Werror=implicit-function-declaration might

    From Guillem Jover@1:229/2 to Adrian Bunk on Sat Mar 16 02:40:01 2024
    XPost: linux.debian.bugs.dist
    From: guillem@debian.org

    Hi!

    On Sat, 2024-03-16 at 02:18:22 +0200, Adrian Bunk wrote:
    Package: dpkg-dev
    Version: 1.22.6
    Severity: serious
    X-Debbugs-Cc: Steve Langasek <vorlon@debian.org>

    3. Code that does still compile with -Werror=implicit-function-declaration
    but behaves differently, e.g. due to failing autoconf tests silently
    disabling features

    Debian has automation listing implicit-function-declaration warnings
    in all packages already running for several years: https://qa.debian.org/bls/bytag/W-implicit-declaration.html

    My main worry is point 3, issues like #1066394.

    #1066394 was found due to causing a FTBFS in a different package,
    but the more common case is likely that a program has some
    feature/plugin disabled and this won't be spotted until much later.

    "Much later" might be after the release of trixie a user upgrading
    to bookworm who uses this feature.

    Or it might result in a program silently using an insecure legacy codepath, e.g. after a test for getentropy() failed.

    Not enabling this -Werror might imply ABI breakage for the time64
    transition, which seems pretty terrible too. The way I see it, and
    given the timing, effort and preparation necessary for this transition,
    both options (enabling or not enabling the fatal warning) are potentially
    bad in their own way.

    But given that these are clearly bugs, that not enabling them can imply
    ABI breakage, that if things go according to plan (AFAIK) this will be
    made the default anyway with gcc-14, that we can track those down, and
    people have already been doing that for the Modern-C effort, see:

    https://fedoraproject.org/wiki/Changes/PortingToModernC
    https://wiki.gentoo.org/wiki/Modern_C_porting

    I think we might as well just cope with this anyway right away.

    A large part of the packages in unstable might not get recompiled
    between now and the release of trixie, creating the additional
    issue that any such problem might occur only after a security update
    or point release update if this is the next rebuild of the package
    in trixie.

    AFAIUI (and I'd expect) the whole distribution needs to be rebuilt
    anyway as part of the time64 transition, otherwise the 32-bit ports
    that are affected by it, will not benefit from it. So I don't think
    this should be a concern.

    So I'm inclined to close this, and consider the current state, the
    less bad one. :/

    Thanks,
    Guillem

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)