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

[Mario Domenech Goulart]

On Fri, 20 Nov 2015 19:06:33 +0100 Peter Bex <address@hidden> wrote:

> 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.

Great work, Peter!  Thanks a lot.  I've pushed your patch to both master
and chicken-5.

Best wishes.
Mario
-- 
http://parenteses.org/mario