[Chicken-hackers] [PATCH] Fix #1136 and a question about type specialisation

[Peter Bex]

Hi all,

Here's a simple patch for #1136, which is more-or-less the same bug as
the one pointed out by Mario for string-copy!, but for move-memory!
There's a second bug in the type specialisation for move-memory!: it
would expand to C_w2b(), which is a macro which was defined locally to
lolevel.scm.  Luckily, the macro's expansion was identical to the
expansion of C_bytes() so that's easy to fix.  I decided to use C_bytes
in lolevel.scm as well; no need to have duplicate definitions of the
same thing.

I recommend that this patch is cherry-picked into the stability branch,
just like the string-copy! bugfix was.

Finally, when I wrote the original patch two weeks ago, I ran into
a nasty bug that I thought was hidden very deeply, but turns out to be
pretty simple: As you can see in the original patch at
https://bugs.call-cc.org/attachment/ticket/1136/move-memory.patch
I initially changed runtest.sh to compile with -O3, which would
perform flow analysis (scrutiny) in order to force out the bug in
the type specialization.  I only needed -specialize (which I used now),
but with -O3 the test kept failing on the assert following the
object-become! call:

(object-become! (list (cons some-foo '(1 2 3)) (cons some-bar '#(1 2 3))))
(assert (pair? some-foo))

The problem here is that object-become! mutates the entire type of the
object.  The scrutinizer doesn't understand that this happens, so it
happily optimizes and replaces the assertion with a call to ##sys#error,
because there's *no way* that the vector "some-foo" can be a pair,
right? ;)

I'm unsure how to fix this.  Is it fixable at all?  Is it worth fixing?
Perhaps we should get rid of object-become!; I'm not sure how useful it
is (only one egg uses it: protobuf), and it just causes trouble.

Cheers,
Peter
-- 
http://www.more-magic.net

0001-Fix-bug-in-move-memory-for-overlapping-memory-region.patch
Description: Text document