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
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
On Oct 8 2011, Alan Post wrote:
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
There is one more - very interesting - occurrence of valgrind
complaints, which point towards some possible (or highly probably
that is) issue.
# Current Situation
I've got a pretty complex program from which I'm trying to derive
test cases. At this time I see this program run for quite some
Given the odd behavior you're experiencing, I would suggest
expanding your test case:
(display (equal? *all-chars*
*all-chars*)
(current-error-port))
(newline (current-error-port))
(display (equal? `(/ ,(integer-char 0)
,(integer-char
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? `(/
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
