Some 64bit issues.

[Rob Browning]

I've fixed a good number of the problems on the alpha now (hoping to
fix that one first, figuring that it's less experimental than the
ia64), and I've got some observations/questions.

There are a bunch of places in the code where we use bit ops with
constants that we don't qualify.  One particular example/problem is in
the srfi-14 code.  We say things like:

  1 << x

but this is being assigned to a long, and needs the full range of a
long, so this needs to be

  1L << x

Also, instead of fixing every call, I changed SCM_MAKE_CHAR to coerce
it's arg, x, to an intptr_t.  This fixes all the warnings and some
bugs, but is it more appropriate to add a coercion at the point of
use?  i.e. I'm wondering if this global coercion, in the macro, might
mask other errors.  I haven't thought about this at all yet, so the
answer may be obvious...

There are also a number of places in the code where the string
handling does things like 

  int k = SCM_STRING_LENGTH(foo);

Is this OK?  What happens if someone with 8GB of RAM wants to create a
giant string?  I guess the real question is, what code guidelines do
we want for the types that should be used for things like string
indexes, etc., on the C side.

Oh, and I'll be patching the stable and unstable trees with the bits
I'm sure about once I'm finished.

Thanks

(and thanks to John Goerzen for the use of his alpha.)

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