Re: Discussion about why GNU/Linux system upgrades cause old programs to break

> From: Arsen Arsenović <[email protected]>
> Cc: [email protected],  [email protected]
> Date: Thu, 13 Aug 2026 00:39:10 +0200
> 
> > But, gcc allows you to recover the old behavior (of permitting cetain
> > K&R constructs in C99 and onwards) also, by passing:
> >
> >   -Wno-error=implicit-function-declaration
> >   -Wno-error=declaration-missing-parameter-type
> >   -Wno-error=return-mismatch
> >   -Wno-error=int-conversion
> >   -Wno-error=incompatible-pointer-types
> >
> > I'm not convinced this suffices to restore compatibility, though.
> > Mostly because I suspect most of these programs would've also broken
> > with GCC 13.
> 
> Not sure how it slipped my mind but, obviously, these are covered by
> -fpermissive.  Quoting (gcc) Warning Options:
> 
> > ‘-fpermissive’
> >      Downgrade some required diagnostics about nonconformant code from
> >      errors to warnings.  Thus, using ‘-fpermissive’ allows some
> >      nonconforming code to compile.  Some C++ diagnostics are controlled
> >      only by this flag, but it also downgrades some C and C++
> >      diagnostics that have their own flag:
> > 
> >           -Wabbreviated-auto-in-template-arg (C++ and Objective-C++ only)
> >           -Wdeclaration-missing-parameter-type (C and Objective-C only)
> >           -Wimplicit-function-declaration (C and Objective-C only)
> >           -Wimplicit-int (C and Objective-C only)
> >           -Wincompatible-pointer-types (C and Objective-C only)
> >           -Wint-conversion (C and Objective-C only)
> >           -Wnarrowing (C++ and Objective-C++ only)
> >           -Wreturn-mismatch (C and Objective-C only)
> >           -Wtemplate-body (C++ and Objective-C++ only)
> > 
> >      The ‘-fpermissive’ option is the default for historic C language
> >      modes (‘-std=c89’, ‘-std=gnu89’, ‘-std=c90’, ‘-std=gnu90’).

Please consider the plight of the person who bumps into these problems
and needs to solve them so the program (which built and worked for
ages) will build again.  At the very least, they need to:

  . realize such an option exists
    - indexing of the manual is not a great help here: there are no
      index entries in the Concept Index leading directly to it; a
      few entries that mention some of the relevant warnings do lead
      to the "Warning Options" node, but the node is very long
  . read and understand the description of each of the -Wfoo warnings
    it disables and decide whether it's applicable and if so, whether
    it's desirable to disable it
  . preferably understand the significance of C Standard versions to
    which the manual alludes, and their relation to the program's code

This requires non-trivial knowledge of the C Standard and related
subjects, and also non-trivial amount of tenacity, let alone time and
effort.

If this is not evidence how poorly we treat users in such situations,
I don't know what is.