[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Peter Bex
Subject: [Chicken-hackers] [PATCH] Fix off-by-one bug in equal? comparison of closures
Date: Fri, 20 Nov 2015 19:06:33 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

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
$ csc -no-lambda-info test.scm

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.


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

Attachment: signature.asc
Description: Digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]