Re: typedef void *

["Greg J. Badros" <gjb at cs dot washington dot edu>]

Han-Wen Nienhuys <hanwen@cs.uu.nl> writes:

> Hi,
> 
> I'm just working on my typedef void *SCM; patch, and some of the stuff
> I find is dubitable:
> 
> unif.c (around line 314):
> 
>        case scm_tc7_svect:
>              return (SCM_SYMBOLP (prot)
> 		      && (1 == SCM_LENGTH (prot))
> 			   && ('s' == SCM_CHARS (prot)[0]));
> 
> this might return 0.  I suspect someone forgot a SCM_BOOL. That's what
> I'm adding here anyway.

Yep;  looks like lots of bugs in that code (and this is why this patch
is so important!)  All of the:

      return nprot || SCM_BOOL(SCM_BOOL_T==prot);

bits need to be:

      return SCM_BOOL(SCM_BOOL_T==prot);

(the "if (nprot)" case is handled earlier). And the case you list should 
be wrapped in a SCM_BOOL, as you suggest.


> ramap.c is entirely incomprehensible to me. The function raeql is
> schizophrenic: it can return SCM_BOOLs, 0 as well as what comes out
> ramapc().

Looks like a mess to me, too.  I think scm_raequal is supposed to
convert the result of raeql to a SCM, so raeql should just be return 0/1 
(C "booleans").

When in doubt, do what you think is right.  Add a HWN:FIXME:: comment
when you're not certain it's the right thing, or there's an issue you
want someone to look at later.

> Furthermore, throw.c is puzzling to me. Consider the macro JBACTIVE
> 
> 	     #define JBACTIVE(O) (SCM_CARW (O) & (1L << 16L))
> 
> As far as I can tell, this would cause a core dump (referencing the
> nilpointer)

The O, above, is a letter "O", not a zero.  Those macro formal argument
names should *absolutely* be changed.  Whoever used O was just playing
an evil mind game, I suspect.  I'd change all the Os to OBJ or S or
something.

Greg