Rob Browning <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED] PGP key available
_______________________________________________
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel
