Possible bug in g-wrap gw-* code

[Rob Browning]

Derek Atkins <warlord@MIT.EDU> writes:

> No, the warnings are NOT spurious.  They are completely reproducible
> and by code examination you can show that without a-priori knowledge
> there is no way to know that the correct code-path will be taken.

They're spurious in the sense that the variables are *not* ever used
uninitialized.  The compiler just can't figure that out.

> Unfortunately there is no easy way to turn on -Wno-uninitialized just
> for g-wrap-generated source files.

I suspect it is possible to do this with some farily trivial
conventions in the Makefile.am's, but wouldn't be able to say for sure
until I had time to investigate.

> I agree that there is no generic way, but there are three ways:
>
> scalar types can be initialized directly as I suggested earlier.
> non-scalar types can be initialized either by a c-code, or by a
> memset.  Either way would work.

It still bothers me that this memset call (an actual function call on
some platforms) is a complete waste of code.  Imagine the C arg is
something "like double foo[256]" -- doubly initializing it is
pointless.  To make it clear for others less familiar with the
problem, this would result in code similar to this:

  double c_param_3[256];
  ...
  memset (c_param, 0, sizeof (c_param_1));
  ...  
  /* convert c param 1 */
  if (no error)
  {
    /* convert c param 2 */
    if (no error)
    {
      for ()
      {
        c_param_3[i] = convert_from_scm (scm_param_3, i);
      }

or whatever...

I think we just disagree (especially if we can have per-g-wrap-file
compilation options) over whether or not the cure (redundant
initializations) is worse than the disease.  You think it isn't, I'm
not convinced.

In any case, give me a bit of time.  I've thought of something that
might work if it can be done without having to re-write too much of
g-wrap internally, and wouldn't require bolting on stuff just to shut
up the compiler.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD