On Thu, Jul 25, 2013 at 8:48 PM, Dan Gora <dan.g...@gmail.com> wrote:
[...]
>
> Let's consider an example:
>
> int foo(int arg)
> {
>    int i;
>
>    if (arg < 1)
>       i = 1;
>    else if (arg >= 2)
>       i = 2;
>
>    printf("i=%d\n", i);
> }
>
> Now in this case if 'arg' is 1, then the value printed will be
> undefined.  However the compiler will spit a warning "i may be used
> uninitialized" (or something to that effect), so you know that you
> have an unused case there.  If you just blindly initialize 'int i=0;'
> at the top of the function then you will not get that warning.  Maybe
> you really wanted i to be 3 if arg was 1, but you just forgot to
> handle the case where arg == 1.  A better style would be:
>
> int foo(int arg)
> {
>    int i;
>
>    if (arg < 1)
>       i = 1;
>    else if (arg >= 2)
>       i = 2;
>    else
>       i = 0;
>
>    printf("i=%d\n", i);
> }
>
> because then you know that you have all of the cases covered and the
> compiler will not spit a warning about uninitialized variables being
> used.
>
> Now of course there are exceptions to this "rule".  Something like:
>
> int foo (int arg)
> {
>    int ret = 0;
>
>    if (arg)
>      {
>      ret = func1();
>      }
>    return (ret);
> }
>
> Is fine and you see that a lot. In this case you have a known default
> value that you are setting ret to.  You're not just initializing ret
> to something just to initialize it or (worse yet) to get rid of
> warnings about ret being used without being initialized.  However to
> my mind it's better to not initialize ret in the declaration and just
> initialize it close to where it's first used.:
>
> int foo (int arg)
> {
>    int ret;
>
>    /* default to success! */
>    ret = 0;
>    if (arg)
>      {
>      ret = func1();
>      }
>    return (ret);
> }
>
> This just tells me, as a reader, that the author _knows_ that ret may
> not be set by the body of the function and wants ret set to some
> default value.  But this is a minor quibble for small functions.
>
>>> Also, remember that:
>>>
>>> uint8_t data[256] = {0};
>>>
>>> does not zero all the elements of 'data', only the first element.
>>
>> Damn! You're absolutely right! I always forget about this. I did write
>> it down this time and I hope I'll remember it from now on.
>> Also, 'data' is being initialized like two lines below. Ehm.
>
>
> yeah that another thing that these patches had.. Something like:
>
> int ret = 0;
>
> ret = scanf(fd.....);
>
> The ret = 0 in the declaration is totally unnecessary (and will just
> be optimized out) since we're immediately going to set ret to the
> return value from scanf.
>
>
>> The problem is nobody does it(init).
>> And further you go from your
>> declarations the easier is to forget about it. Then only one bit is
>> initialized and the rest of structure is left at "random". But this is
>> beyond discussion whether to initialize in the declaration or later in
>> the code.
>> Simply - ok.
>
> I agree, there are not hard and fast rules for everything, you have to
> use a bit of sense, I'm just saying that it's better not to do the
> initialization in the declaration unless there's a good reason to
> since it can suppress these valuable compile-time warnings.
>
> thanks
> dan

Oh, I see your point now. I was thinking something different - CPU
code execution optimization etc.
It makes sense, especially in case of somebody's else code, but it
will be hard to fight/resist doing it.

Thanks for explanation,
Z.

------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Ipmitool-devel mailing list
Ipmitool-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ipmitool-devel

Reply via email to