bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 1/2] inet_ntop: silence gcc warning


From: Eric Blake
Subject: Re: [PATCH 1/2] inet_ntop: silence gcc warning
Date: Wed, 11 Jan 2012 17:01:43 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0

On 01/11/2012 04:44 PM, Paul Eggert wrote:
> On 01/11/12 15:24, Eric Blake wrote:
>> +  best.len = 0;
> 
> I have some qualms about adding unnecessary initializations
> merely to silence GCC.  It's not just that it bloats the
> runtime -- it's that it makes the code more confusing, because
> later readers might mistakenly assume that the initializations
> are necessary, which might cause them to waste time trying to figure
> out why the initializations are there.
> 
> How about if we put that assignment inside an "#ifdef lint",
> or wrap it in IF_LINT, or something like that?  That should
> make it clearer and avoid the runtime bloat.

But putting it inside #ifdef lint means you won't solve the compilation
warning in the default case.  And in this case, it took me several
minutes of staring at the code to see _why_ the variable was never used
uninitialized - no wonder gcc -O2 had problems coming to the same
conclusion.  All uses of best.len are gated behind an earlier
short-circuiting check of best.base != -1, while the only assignment to
best.base is via the assignment of best = cur; which in turn means you
have to prove that cur.base is assigned on all paths that reach the
'best = cur' statement, which involves reasoning through multiple
iterations of the loop body.  And in this particular case, setting
best.len to 0 _is_ appropriate for the algorithm at hand (finding the
longest sequence of consecutive 0 bytes, where we start with a length of
0).  At least to me, seeing the explicit initialization made it easier
to reason about the algorithm, rather than trying to figure out whether
the initialization was necessary.

-- 
Eric Blake   address@hidden    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]