[Chicken-hackers] [PATCH] Fix off-by-one bug in equal? comparison of closures

[Peter Bex]

Hi all,

After some detective work, I finally fonud the cause for #1041.  Nothing
mysterious, not even the hash tables are to blame.  It turns out
awful-path-matchers was relying on equality of closure objects, which is
of course a bit iffy, but it isn't necessarily *wrong* (depending on what
you're expecting of it), but CHICKEN would incorrectly say two procedures
are equal? when they definitely weren't.

Here's a simplified example:

$ cat test.scm
(define (constantly x) (lambda () x))
(print (equal? (constantly (string)) (constantly (string))))
$ csc test.scm
$ ./test
#f
$ csc -no-lambda-info test.scm
#t

The example doesn't use constantly from data-structures because
that's typically compiled with lambda-info enabled!

Anyway, the culprit is a very simple mistake: instead of using
memcmp to compare the data slots, it accidentally started at the
header, thereby omitting the final slot from the comparison.  This
last slot will contain the lambda info.

So before, it would see a procedure with 2 slots (the C function
in the special first slot, and the fresh string in the second slot)
or with 3 slots in case of lambda info.  The headers are always
identical because the length & type are the same, so it would only
be comparing the C function address, which is in this case the same
also.  If lambda info was enabled, it would see 3 slots and compare
the header, C function address and the fresh string which always
differs in both objects.

Cheers,
Peter

0001-Fix-equal-comparison-of-closures.patch
Description: Text Data

signature.asc
Description: Digital signature