[Top][All Lists]

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

Re: [Chicken-users] Crash in SRFI-69 eq?-hash

From: Thomas Chust
Subject: Re: [Chicken-users] Crash in SRFI-69 eq?-hash
Date: Sun, 19 Aug 2018 14:48:28 +0200

On Sun, 19 Aug 2018 14:08:38 +0200 address@hidden wrote:

> [...]
> I checked the code and, for number types, only fixnums and flonums are
> explicitely handled, other numeric types trigger an incorrect recursion. 
> It seems we forgot to add support for the new numeric types to srfi-69
> when we introduced them.
> [...]


thanks for taking the time to look into this!

Your explanation makes a lot of sense, I also suspected the newly added
numeric tower support in core may have broken some low-level
type-specific logic. I just didn't understand enough of the magic
around ##sys#object->uid, for which I couldn't immediately find any
definition in the CHICKEN source, to get a firm grasp of how the
default hash functions in srfi-69 work at all.

For the moment being I have implemented a hackish workaround using

  (define %eq?-hash
    (foreign-lambda* int ([scheme-object v] [int bound])
      "C_return((((intptr_t) v) >> C_FIXNUM_SHIFT) % bound);"))

which is probably terribly incorrect in case the garbage collector
moves objects around, but memory load seems low enough and table
lifetimes short enough in my use case for this to work momentarily %-]


There are only two things wrong with C++: The initial concept and the
-- Bertrand Meyer

reply via email to

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