[Top][All Lists]

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

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

From: Jörg F . Wittenberger
Subject: Re: [Chicken-users] more: news from the valgrind front - another test case
Date: 08 Oct 2011 21:16:02 +0200

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

Urgh.  Don't tell me I'm waiting for the ARM to compile the whole sh*
to eventually find out that there is another problem with it.

It still compiles (I don't have a working cross-compile setup.  Do you?
Last time I begin to set up one more pressing things came in.
Which tutorial would be the best one?) - I'm tired to wait.

Alan, you are true: the C_unfix just above appears to be very similar.
But: as far as I read the source, I'd say: C_unfix is being applied
to arbitrary sized words and the receiving word decides how wide
the result shall be.  True?  In that case the cast would not be

At the other hand: in theory this cast should never hurt.
In fact, to be safe it should be always applied even if it's not
explicit required.  If this theory holds, than there are several
defines close by, which would have to be revised.

At the practical end: eventually all those bugs will raise their head.
Just changing all at once looks quite hazardous to me too.

To avoid mangling, I attach the diff this time.  Hope it works better.

Best Regards


Attachment: mkchar.diff
Description: mkchar.diff

reply via email to

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