Possible bug in g-wrap gw-* code

[Rob Browning]

Matthew Vanecek <mevanecek@yahoo.com> writes:

> Since we don't want to turn warnings off, but we don't really want
> to see warnings for things we the developers have ostensibly
> accounted for, the proper thing to do would be to initialize these
> variables to NULL in the declaration.  That would quiesce the
> compiler warnings without adversely affecting the code.  I have no
> idea how to do that in the scheme spec files, myself.

Derek and I have actually been talking about this for a while.  It's
not actually a bug, but rather a tradeoff.  The reason the code is
emitted the way it is has to do with allowing each wrapped parameter
to have it's own nested scope so it's pre and post ccodegen's can talk
to each other via their own local variables without having to have
separate "param-declarations-ccg" and "scm->ccg"'s.

I believe the uninitialized warnings are as you mention spurious.
There's no way the variables can actually be used without being
initialized, but you're also right that detecting that automatically
would be quite hard.  The gcc manpages actually list this type of case
as a "problem", and it's too bad they don't also provide an
"__attribute__ ((presume_initialized))" or something.

One way to fix this would be (as you mention) to just initialize the
wrapper c param variables where they're declared, but the question is
"initialize them to what"?  In general these variables could be
complex structs, structs that only the scm->c ccodegen knows how to
initialize.  One solution to that would be to add an
"c-param-init-ccodegen", but these would serve no purpose other than
to satisfy the compiler -- or to put another way -- whatever code they
generate to initialize the variable would be a waste of cycles.

However I realize that this problem is annoying and may hide errors,
and I'm all in agreement wrt the usefulness of -Werror (having been
one of the people who pushed for it initially in gnucash and did a lot
of the auto* work to make it possible), but I'm just not sure what to
do about it.  Maybe it's worth the extra CPU cycles, and complexity in
the g-wrap api just to shut up the compiler...

I have been thinking about it a bit, and here are the possibilities I
see:

  - perhaps figure out an automake strategy (via @@ vars or whatever)
    that would allow -Wno-uninitialized to be used only on the g-wrap
    generated files.

  - re-work g-wrap to add c-param-init-ccg's (initialization
    ccodegens) with a default that just does something like Derek has
    previously suggested "foo = (void) 0" (though we'd have to make
    sure we pick something portable -- i.e. do we need 0L rather than
    0? etc.  However, this would mean that for non-trivial types,
    you'd have to provide an initializer, and whatever work is done by
    any of these initializers is essentially superfluous code.

  - see about reworking g-wrap to use a different approach to the C
    param nesting, etc. when assigning args.

The final option, if possible would be the best solution, but as I
recall there were enough constraints on the solution (given the
current codebase, problem itself, etc.) to make finding a good one
tricky.

Let me look in to the last option now that I've fixed the other g-wrap
problems (locally), and have re-familiarized myself with the code.
I'll see if I can come up with a better solution this time around.

Thanks

-- 
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