Possible bug in g-wrap gw-* code

[Derek Atkins]

Rob Browning <rlb@defaultvalue.org> writes:

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

I would argue that the number of cycles for initialization is rather
small..

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

I've looked into this and there is no easy way to do this.  The
version of automake we require (1.4 -- which is the default on RH7.3)
only provides a per-directory AM_CFLAGS.  Newer versions of automake
do enable per-library CFLAGS, but it still wont let us do this
per-file.  Besides, this means you have to hack around the issue every
time you use g-wrap, so it's not a "change once and fix everything"
option like your next two...

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

I believe this is the easiest to implement.  My personal feeling is
that the superfluous initialization is rather small compared to the
rest of work being done.  I know we disagree on this point. :)

Also, I am fairly confident that a cast of '0' to any type is
sufficient for any scalar type in ANSI-C.  My reasoning is that the
cast will sign-extend the 0, so it will do the right thing (provided
you cast..  You can't do "<type> <name> = 0;" and have it necessarily
work in all cases.

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

I agree that the last option would certainly be the best, but it is
also probably the most amount of work.

> 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!  All of us appreciate your help here..

> Thanks

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available