Shouldn't we be developing with TYPING_STRICTNESS=2?

[Rob Browning]

(or at least testing regularly?)

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

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.

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.

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?

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
    
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.

-- 
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