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