Re: Shouldn't we be developing with TYPING_STRICTNESS=2?

[Dirk Herrmann]

On Thu, 13 Sep 2001, Rob Browning wrote:

> (or at least testing regularly?)

The point is, that you can't generate actual code with
TYPING_STRICTNESS=2.  See below for an explanation.

> And as an orthogonal question, is guile supposed to work on 64 bit
> archs right now?

I don't know.  However, I think there is a lot of code in guile that is
not very strict with respect to typing.

> While trying to check up on the ia64 bug, I turned typing strictness
> up to 2, and I notice a lot of suspicious code.  For example, in
> backtrace.c, there are lots of
> 
>   (foo == *bar)
> 
> where foo and *bar are SCM's.

I will fix these.

> Also, there's a call like this
> 
>   if (SCM_EQ_P (SCM_SHOW_FILE_NAME, sym_base))
> 
> which fails because SCM_SHOW_FILE_NAME grabbs a scm_t_option's val,
> but that's unconditionally defined to be an "unsigned long", rather
> than an SCM.

That is a problem with the implementation of the options.  We could
probably add some hacks to macros like SCM_SHOW_FILE_NAME as a workaround,
but I would prefer the options implementation to be revised.  We should,
however, don't add hacks for the compilation with TYPING_STRICTNESS=2,
since (as I will explain below) you can't generate code for it anyway.

> We've also got some "pointer fits in int" assumptions...  i.e.
> 
> in error.c:
> 
>     int error = (int) pos;
> 
> causes a warning -- pos is a cptr.  You can fix it with ((int) (long)
> pos), but isn't there something more portable, or is long always
> guaranteed to be large enough for a ptr?

Hmmm.  Isn't intptr_t meant to fulfill that requirement?

> and in eval.c, some bigger problems (though they may be known):
> 
>   eval.c:1291: case label does not reduce to an integer constant
>   eval.c:1294: case label does not reduce to an integer constant
>   eval.c:1297: case label does not reduce to an integer constant

These error messages are the reason why the generation of code with
TYPING_STRICTNESS=2 is not possible.  The trick with TYPING_STRICTNESS set
to 2 is to define SCM as a struct.  This makes all of C's implicit type
conversions impossible and is the reason why this mode allows the best
possible type checking by the compiler.  However, if SCM is a struct this
means that constants like SCM_BOOL_T are also structs.  And, you can't use
structs as case labels.  There are some other places in which C does not
allow structs - initializations are a problem as well.  You can't declare
a variable as  " SCM foo = SCM_BOOL_F "  if SCM_BOOL_F is a struct.

(This is, simplified, the explanation.)  However, why to we have
TYPING_STRICTNESS=2 then?  The point is, that this mode detects a lot of
potential problems with typing in ordinary code.  We have to live with the
fact that other code will not compile in that mode.

> Presuming our tests in tags.h actually do some good, it might be wise
> for people to develop with typing strictness set to 2, and then turn
> it down for the release.  I also believe that developing with
> --enable-error-on-warning would be wise.

Well, for normal development typing strictness set to 1 should be
sufficient.  However, from time to time a compilation with
TYPING_STRICTNESS=2 should be done, especially with an upcoming release.

Best regards
Dirk Herrmann