[ipxe-devel] [PATCH] [infiniband] Fix uninitialized variables warning

[Michael Brown]

On Tuesday 01 Jun 2010 19:24:36 Miller, Shao wrote:
> In general, is it preferable to walk all code paths for uninitialized
> values in the iPXE code, rather than initialize to defaults at
> declaration time?  Is that because the decreased code size benefit is
> not worth the trade-off for erroneously reported defaults/success?  I'll
> try to stick with whatever preference you've established, if you don't
> mind clarifying.  Thanks.  - Shao

For error status codes, I tend to use the pattern of an uninitialised variable 
whose value is set only when the error occurs.  This, in theory, forces me to 
ensure that each error code path sets the appropriate error status, since the 
compiler should complain if I miss one.  (I don't know why gcc 4 doesn't 
complain about the uninitialised variables in this case.)

GCC is generally pretty good at collapsing duplicate code paths, so a whole 
set of

  if ( ! success_1 ) {
    rc = -ENOMEM;
    goto error_out;
  }
  if ( ! success_2 ) {
    rc = -ENOMEM;
    goto error_out;
  }
  ...
  error_out:
    return rc;

will generally get optimised to be equivalent to

  if ( ! success_1 ) {
    goto error_out_enomem;
  }
  if ( ! success_2 ) {
    goto error_out_enomem;
  }
  ...
  error_out_enomem:
    return -ENOMEM;

i.e. there is generally no size penalty to explicitly setting rc in each 
individual error path.

The "supported" variable in qib7322_link_speed_supported() is a similar 
pattern in that I would like there to be a compilation error if any of the 
switch cases forgets to set a value.

Michael