More g-wrap bogosities
Derek Atkins
warlord@MIT.EDU
13 Jan 2002 13:47:54 -0500
Rob,
g-wrap appears to be generating code that looks like this:
{
enum GW__ErrorStatus gw__tmp564_status_var = GW__ERR_NONE;
SCM gw__tmp566_err_data = SCM_UNSPECIFIED;
char *gw__tmp565_err_misc_msg = NULL;
}
Yes, this is an actual verbatim cut-and-paste from gw-app-utils.c,
around line 2620.
Yes, this code would clearly be optimized out by the compiler. But
why can't you generate a code block that looks like:
{
enum GW__ErrorStatus gw__tmp564_status_var = GW__ERR_NONE;
SCM gw__tmp566_err_data = SCM_UNSPECIFIED;
char *gw__tmp565_err_misc_msg = NULL;
(void)gw__tmp564_status_var;
(void)gw__tmp566_err_data;
(void)gw__tmp565_err_misc_msg;
}
Clearly I need to look closer at the g-wrap architecture, but doing
something like this shouldn't be too hard, IMHO.
I agree that solving the other "initialization" problem might be
more of a challenge.
-derek
Rob Browning <rlb@defaultvalue.org> writes:
> Derek Atkins <warlord@MIT.EDU> writes:
>
> > Why can't you just always add "(void)<varname>;" for every
> > variable/argument and always initialize stuff? Don't worry about
> > whether the argument is used or not; just add a line for all of
> > them. As you say, g-wrap is already designed for the compiler to
> > optimize away unused code, and any decent optimizer will certainly
> > work around this construct....
>
> Well, then this would mean that for every type that people want to
> define (via gw:wrap-type), we'd have to
>
> (a) require that in addition to all the other things they have to
> specify (i.e. c->scm-codegen, scm->c-odegen, c-destructor, etc,
> we'd also have to have them define an initializer). Not a huge
> deal, but unnecessary -- the person defining the g-wrap type
> wrappers has to specify a pointless piece of information just
> because the C compiler isn't quite smart enough (see below).
>
> (b) we'd have to use these initializers for every wrapped arg, even
> though the initialization is a total waste of code because,
> unless there are errors, those initializations will be blown
> away in short order by the scm->c converters for each arg.
>
> The big problem here is that the C compiler is just not smart enough
> to know that these variables really aren't ever used without being
> initialized, and if it can't figure that out, I don't trust it to
> figure out that the initializations in (b) above are always pointless
> and ignore them.
>
> The real underlying problem is that the wrapper code looks kind of
> like this:
>
> CType1 c_arg1;
> CType2 c_arg2;
> CType3 c_arg3;
>
> c_arg1 = scm_to_c_Type1(scm_arg1, &status_var);
> if(status_var != GW__ERR_NONE) {
> set_some_error_codes...;
> } else {
> c_arg2 = scm_to_c_Type2(scm_arg2, &status_var);
> if(status_var != GW__ERR_NONE) {
> set_some_error_codes...;
> } else {
> ...
> ...
> c_result = some_c_func_call(c_arg1, c_arg2, ...);
> if(status_var != GW__ERR_NONE) ...
>
> }
> /* c_arg2 post-call processing code, if any goes here (in same
> scope as pre code */
> }
> /* c_arg2 post-call processing code, if any goes here (in same
> scope as pre code */
>
> if(status_var == GW__ERR_NONE)
> return scm_result;
> else
> gw__handle_error(status_var, various, bits, of, data ...);
>
> The reason for this structure is that we need a way to allow wrapped
> type's generated code to handle conversion errors while still making
> non-error cases reasonably fast.
>
> In any case, as you can see, there's no way that any of the c_args can
> be used without being initialized, but the compiler doesn't figure
> that out so we just have to tell it -Wno-uninitialized.
>
> There's a similar argument to be made for -Wno-unused. As an example,
> g-wrap doesn't have any idea what code a given type is going to
> generate to convert its arguments back and forth, so g-wrap has no
> idea, for example, if the code generated by all of the type conversion
> code for a given function's argument types and return value type will
> reference the error signalling variables. Since it can't know that,
> it has to declare them just in case.
>
> "Fixing that problem" would quite possibly involve either making
> g-wrap less flexible (in terms of what a type's code generators are
> allowed to look like) or might make g-wraps internals more
> complicated.
>
> Either way, I haven't had a lot of time to make sure I can't think of
> a better solution, but since the two -Wno arguments fix the problem,
> I can't justify spending a lot more time thinking about it right now.
> I've already used up my g-wrap time allocation for a while. However,
> if you can think of something better, that'd be great.
>
> > Is it a lot of extra infrastructure to keep a list of all the
> > variables and just output a set of 'compiler warning fixes' for them?
>
> How would I keep a list of variables? All g-wrap knows about a type's
> code generators is that it calls them with some arguments, and they
> return a string-tree of c-code that is dumped to C output files at the
> right times. Unless g-wrap's going to parse that C code, it can't
> know what it's doing.
>
> Actually, that's not entirely true -- at least for the error status
> variables, g-wrap requires the types to access those indirectly, so in
> theory it might be able to keep closer track, but off the top of my
> head, I think doing so would require a non-trivial amount of extra
> code, and the benefit doesn't really seem worth it yet.
>
> > I still might take a look at g-wrap and see if I can supply a fix to
> > output what I think will fix the warnings.
>
> Cool.
>
> If you need help understanding what's going on, just holler. In
> truth, I think the next best g-wrap expenditure of my time would be in
> updating the documentation to reflect the overhaul. The existing docs
> are now nearly useless.
>
> --
> 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
--
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