Re: [Sbcl-devel] ./sbcl --core ./something-with-embedded-core (why not?)

[Anton K. <an...@sw...>]

David Lichteblau <da...@li...> writes:

> BTW, regarding other related changes in your tree (SBCL_HOME removal) --
> those are very nice ideas, but I'd like to wait for Nikodemus' similar
> changes to go into master first.

As of SBCL_HOME and relatives, I would recommend against merging my
changes (as they currently are) anyway. What's desperately needed here
is a kind of abstraction (for "self/exe", for argv, etc) that would
allow some platforms to use ASCII-compatible encodings, while other
platforms would use UCS-2. 

I merely applied some duct tape and bubble gum to that code, to have
some minimal support for ucs-2 and "homeless" installations, yet without
perpetual conflicts when I'm tracking the mainline's trunk; it took much
time to realize that src/runtime/ is one of the safest parts of the
whole tree w.r.t. VCS conflicts (and this observation is likely to
become obsolete soon, when Nikodemus Siivola dives into threading).

BTW, are there any consensus about the right way to spell "[un]signed
pointer-sized integer" on L32P64 platforms? IIRC, I've posted a similar
question earlier, hoping to learn whether uword_t and sword_t are
acceptable (well, at least they are mechanically replaceable; after all
that hunting for longs and their stray [un]signeds, with unintended
collateral damage to both kinds of long longs, I would be glad to avoid
similar experience once again). My conclusion so far is that u64 and s64
were appropriate.  Earlier I was much confused by some Alpha-specific
code disagreeing with this assumption; but I've read of a peculiar
nature of Alpha port since that time, so there may be nothing wrong with
u64/s64 still.

-- 
Regards, Anton Kovalenko
+7(916)345-34-02 | Elektrostal' MO, Russia