[chuck-dev] 64-bit ChucK (once more unto the breach)

[Drake Wilson]

Hum.  So, searching the mailing list archives, I find several people
reporting that compiling ChucK on any 64-bit platform segfaults
immediately on startup due to assumptions about type widths.  This is
also my experience.  This should be unsurprising to me by now, but
apparently I can still be toppled over backwards by this sort of
stuff, so pardon me if I flame somewhat.

I'm not going to ask for a fix date or anything like that.  I'd love
to fix it myself, ideally, though I have no idea whether I'll have a
chance to do that.  What I will ask, however, is _why_?  I see no
response to this in any of the earlier threads (possibly because
nobody asked), only vague rumblings about "it doesn't work on 64-bit
machines yet; we're still working on it".

Which assumptions is ChucK making about type widths, and why is it
making them?  A cursory inspection of the source seems to indicate
that someone decided long must be four bytes on every machine and
happily hardcoded it everywhere, thus making it almost impossible to
dig the all-the-world's-an-i386 syndrome out now that it's sunk so
deep into the VM and such.  Is that what it is, or is it something
else?  Are there other similar nonportable assumptions (aside from the
stuff that's actually demarcated as platform-specific)?

What compels people to not use mechanisms like sizeof for this sort of
thing?  I don't see anything doing fancy enough tricks to legitimately
depend on assumptions like that.  I'm honestly stunned.  I decided to
try ChucK instead of SuperCollider because SuperCollider stupidly
assumes it can stuff a void * into an int, which makes it not compile
on my machine, so I immediately gave up on it.  I was getting my hopes
up because ChucK at least compiled, but now I find that a similar form
of bogosity will probably destroy any reasonable chance at that too.

At any rate, it would be nice to check at compilation-configuration
time, or even at process initialization time, that all the sizes fit
whatever constraints they're required to fit, and then bomb in a
well-defined manner if they don't.  There being no obvious
compilation-configuration stage seems to make the former possibility
into more of a mess than it should be, of course, so meh.

   ---> Drake Wilson