Bill Gribble <[EMAIL PROTECTED]> writes:
> On Sat, 2002-10-19 at 11:43, Matthew Vanecek wrote:
> > Anyhow, the above type of warnings generate over 1000 lines of warnings,
> > so it should be taken care of.
>
> Getting rid of these warnings would require a significant
> re-architecting of g-wrap and it's unlikely to happen anytime soon as
Actually, this is not true. I came up with an architecture where
you only need to define an initalizer for non-scalar types (of which
there are few, but not many). Any scalar type can be initalized by:
type name = (type)0;
I've already sent Rob some patches that do this for some g-wrap types,
but it doesn't work for simple-types (because of the non-scalar
initialization problem).
My suggested fix is to add a 'c-initializer' field which only needs to
be set for non-scalars.
> far as I can tell. The warnings are spurious, as you point out. I
> agree that it would be nice for them to go away, but it would be much
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.
> easier just to turn off warnings with -Wno-uninit for compilation of the
> g-wrap generated files.
Unfortunately there is no easy way to turn on -Wno-uninitialized just
for g-wrap-generated source files. It's an all-or-nothing game, and
frankly I consider an uninitialized variable to be a bug. I don't
want that to be hidden from me.
> The problem is that there's no generic way to initialize C variables,
> and g-wrap is generating C code programmatically. Without including a
> bit of C code to "default initialize" a C variable in the g-wrap file
> for every wrapped C type, g-wrap can't know that a decent default
> initializer is { 0, NULL, 0, NULL } for some random struct but just 0 or
> NULL for some other type.
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.
> So, it would require a significant amount of work to do in any case, and
> would provide exactly 0 improvement in safety of run-time code while
> making more room for g-wrap wrapper generators to insert screwups that
> would silently cause problems.
I disagree that it would be a significan amount of work. I fixed most
of the issues already and sent patches to Rob -- the only issue left
is "simple types". And, as I said, it could easily be done by an
extra function that needs to be called for non-scalars (or it can be
an extra parameter).
Sure, it means that you have to touch the code in a lot of places, but
it's not a lot of _work_, per se (although it may be a bit tedious).
It is certainly not _hard_, considering most of the hard work I've
already done.
> BTW, [EMAIL PROTECTED] doesn't work any more. You might try
> [EMAIL PROTECTED] if you want to get Rob directly.
>
> b.g.
-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
