Re: [PATCH 1/2] DONTAPPLY: -Og fallout workaround

[Patrick Steinhardt <ps@pks.im>]

[-- Attachment #1: Type: text/plain, Size: 3241 bytes --]

On Mon, Jun 10, 2024 at 01:05:00PM -0700, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
> 
> > These "workarounds" are to mark variables that are used after
> > initialized, but some compilers with lower optimization levels
> > cannot see and report "used uninitialized".
> >
> > This set targets "gcc-12 -Og".  For the reason why this is a wrong
> > thing to do for longer-term code health, see
> >
> >   https://lore.kernel.org/git/xmqqed946auc.fsf@gitster.g/
> >
> > Signed-off-by: Junio C Hamano <gitster@pobox.com>
> > ---
> >
> >  * Even though I said I won't do the actual patch, since I had to
> >    gauge the extent of damage, I ended up doing so anyways.
> >
> >    As I explained already, the size of this patch, i.e. number of
> >    places that need the workaround, does not really matter.  What
> >    is horrible is how each of these workaround will hide real bugs
> >    we may introduce in the future from the compilers.
> >
> >  builtin/branch.c          | 2 +-
> >  builtin/fast-import.c     | 4 ++--
> >  builtin/repack.c          | 2 +-
> >  fetch-pack.c              | 2 +-
> >  http-backend.c            | 2 +-
> >  http.c                    | 2 +-
> >  pack-mtimes.c             | 2 +-
> >  pack-revindex.c           | 2 +-
> >  refs/packed-backend.c     | 2 +-
> >  reftable/stack.c          | 2 +-
> >  remote-curl.c             | 4 ++--
> >  t/helper/test-ref-store.c | 2 +-
> >  trailer.c                 | 4 ++--
> >  13 files changed, 16 insertions(+), 16 deletions(-)
> 
> And depending on the version of compilers, apparently even this is
> not enough.  I do not offhand know what GitHub CI is running for
> linux-gcc-default (ubuntu-latest), but this gets flagged for using
> (try to guess which one without looking at the answer below) ...
> 
>         static int parse_count(const char *arg)
>         {
>                 int count;
> 
>                 if (strtol_i(arg, 10, &count) < 0)
>                         die("'%s': not an integer", arg);
>                 return count;
>         }
> 
> ... count uninitilaized, since the compiler does not realize that
> strtol_i() always touches "count" unless the function returns
> negative, and die() never returns.  Exactly the same pattern
> continues.
> 
> So, unless we disable -Werror, let's not continue this experiment
> with -Og or -Os as the damage seems to be far greater than the
> benefit (which I haven't seen any, but that is largely due to
> timezone differences---I asked "what's the real bug you found with
> this" a few hours ago that is past EOB in Europe).

The real bug that "-Og" would have been able to detect was reported by
Peff via [1]. In this case it wasn't "-Og" that detected it, but
Coverity did. But it would have been detected if we had a job that
compiled with "-Og".

But now that I see the full picture of this with different compiler
options I have to agree that this is not really worth it. Especially not
given that Coverity is able to detect such cases, even though that only
happens retroactively after a topic has landed.

Let's drop this experiment.

Patrick

[1]: 20240605100728.GA3440281@coredump.intra.peff.net

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]