Re: [Chicken-users] more: news from the valgrind front - another test case

[Alan Post]

On Fri, Oct 07, 2011 at 10:49:42PM +0200, Jörg F. Wittenberger wrote:
> On Oct 7 2011, Alan Post wrote:
> 
> >Given the odd behavior you're experiencing, I would suggest
> >expanding your test case:
> 
> Good point.  Here the results:
> 
> Now watch the interesting value (should be all 4 true a/a,i/i,a/i,i/a):
> #t#t#f#f
> 
> That is:
> (equal? *all-chars* *all-chars*)
> => #t
> (equal? `(/ ,(integer->char 0)
>                    ,(integer->char #xD7FF)
>                    ,(integer->char #xE000)
>                    ,(integer->char #x10FFFF))
>                `(/ ,(integer->char 0)
>                    ,(integer->char #xD7FF)
>                    ,(integer->char #xE000)
>                    ,(integer->char #x10FFFF)))
> => #t
> (equal? *all-chars*
>                `(/ ,(integer->char 0)
>                    ,(integer->char #xD7FF)
>                    ,(integer->char #xE000)
>                    ,(integer->char #x10FFFF)))
> => #f
> (equal? `(/ ,(integer->char 0) ,(integer->char #xD7FF)
>      ,(integer->char #xE000) ,(integer->char #x10FFFF))
> *all-chars* )
> => #f
> 
> Or: comparison of just initialised value fails to be equal?
> to the literal value.
> 
> Can you/anyone reproduce this result?
> 

It would assume, looking at this output, that *all-chars* is not the
value of the string you're comparing it too:

 * it compares #t to itself.
 * the list compare #t to itself.
 * they don't ocmpare #t to each other.

This suggests that *all-chars* has some value other than what you'r
comparing it to.

-Alan
-- 
.i ma'a lo bradi cu penmi gi'e du