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

[Alan Post]

This came to my mail reader manged, I'm not sure I'm reading it
correctly.  I don't think the line breaks were properly preserved.

If I'm reading it correctly, this pattern could well be repeated
incorrectly in other #define lines nearby--I'd want to check
C_unfix, for instance, just looking at the lines in the patch,
rather than chicken.h.

My favorite bug of this sort happens on arm, which has an unsigned,
rather than signed char, and is therefor wonderful for finding
stuff like.

Good find,

-Alan

On Sat, Oct 08, 2011 at 02:09:30PM +0200, Jörg F. Wittenberger wrote:
> Hi all,
> 
> finally I've been able squash that one!
> Turns out to be a one line change to chicken.h .
> Otherwise valgrind is right to complain.  (It shut up now too.)
> 
> The missing cast would allow the compiler to write only sizeof(char).
> This turned out to be most often ok (whenever the rest of the word
> are already zero bits), but sometimes the compiler might be smarter.
> That's way this was highly dependant on various compiler options.
> CC-flags that is, not chicken.  And at the same time sensitive to
> all sorts of memory management details, which makes it kinda random.
> 
> Best Regards
> 
> /Jörg
> 
> --- /home/jfw/build/Scheme/chicken-core/chicken.h 2011-10-05
> 00:03:16.000000000 +0200 +++ chicken.h 2011-10-08 14:01:57.770611923
> +0200 @@ -937,7 +937,7 @@
> #define C_demand_2(n) (((C_word *)C_fromspace_top + (n)) < (C_word
> *)C_fromspace_limit)
> #define C_fix(n) (((C_word)(n) << C_FIXNUM_SHIFT) | C_FIXNUM_BIT)
> #define C_unfix(x) ((x) >> C_FIXNUM_SHIFT) -#define
> C_make_character(c) ((((c) & C_CHAR_BIT_MASK) << C_CHAR_SHIFT) |
> C_CHARACTER_BITS) +#define C_make_character(c) ((((C_word)(c) &
> C_CHAR_BIT_MASK) << C_CHAR_SHIFT) | C_CHARACTER_BITS)
> #define C_character_code(x) (((C_word)(x) >> C_CHAR_SHIFT) &
> C_CHAR_BIT_MASK)
> #define C_flonum_magnitude(x) (*((double *)(((C_SCHEME_BLOCK
> *)(x))->data)))
> #define C_c_string(x) ((C_char *)(((C_SCHEME_BLOCK *)(x))->data))
> 
> 
> 
> 
> On Oct 7 2011, 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?
> >
> >(So far valgrind not envolved, just this debug code in irregex-core.scm!)
> >
> >
> >/Jörg
> >
> >
> >
> >
> >
> >_______________________________________________
> >Chicken-users mailing list
> >address@hidden
> >https://lists.nongnu.org/mailman/listinfo/chicken-users
> 

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