Re: [PATCH/RFC] reflog: silence -O3 -Wuninitialized warning

[Junio C Hamano <gitster@pobox.com>]

Jonathan Nieder <jrnieder@gmail.com> writes:

> Date: Fri, 04 Mar 2011 00:54:53 -0600
>
> Starting with gcc 4.5 (r147852, Pretty-ipa merge: Inliner heruistics
> reorg, 2009-05-25), gcc -O3 -Wall warns when building
> reflog_expire_config:
>
>     warning: 'expire' may be used uninitialized in this function [-Wuninitialized]
>
> The cause: starting with that version, gcc realizes it can inline the
> call to parse_expire_cfg_value.  In the error case, 'expire' is not
> initialized and the function returns early, but gcc does not have
> enough information to figure out that this is an error return.
> ...
> Anyway, maybe this can provide some amusement.

It actually provides only puzzlement.  That is obviously a buggy compiler
whose warning cannot be trusted.

I am not suggesting to work this around on the caller side, but I wonder
what effect the usual workaround to tell the compiler that we know it
doesn't understand the validity of this variable by saying:

	unsigned long expire = expire;

have on this?

We obviously do not want to work the compiler bug around in the callee
side by assigning to the variable when we didn't parse anything, but the
change to inline config_error_nonbool() to force this particular version
of the compiler to see the callchain through is _too_ subtle for my taste.
The call-chain horizon the next version of the compiler may stop looking
may be different, potentially shifting the compiler bug around.

I see two solutions (1) do not use -Wunitialized if the compiler is known
to be broken, or (2) initialize the variable to 0 (not the fake "x = x")
on the caller side at the place of the definition (yes, we would waste one
real assignment) if we really need to work this around, or (3) take this
patch.

We could obviously do (2) or (3), but the thing is, I don't think we can
have much confidence on -Wuninitialized warnings from this compiler once
we go down that route.  Is it _guaranteed_ that the compiler bug _always_
err on the false-positive side?

IOW, I'd very much prefer (1) for this particular case and if somebody
really cares (2).

Well, it indeed turned out to be amusing, at least for some definition of
the word ;-). I was starting to feel somewhat depressed watching news
programs from Japan on ustream.