On Mon, 16 Nov 2009, Les wrote:
Given that I have seen all kinds of effects in C code, but generally
from compilers that are not "ISO standard" what ever that really means
(ISO is not cast in stone by any means either when it comes to almost
all things).
The standards of interest are written down.
Most things don't change much, if at all, from one verion to another.
But some things have to work for programs to compile and run across
platforms.
The basic copy function which is in most text books:
*a++=*b++;
for example, but I have seen compilers break this bit of code.
Ouch.
The effects run from:
*++a = *b++
*++a = *++b
*a++ = *++b
I have seen some folks attempt to fix it with parens:
*(a++)=*(b++); but that is probably predictable, but would mean that
Why not (*(++a)) = (*(b++)); ?
Does that not work either?
the pointers would have to be set artificially prior to the call to
point one location earlier, and the exit condition would be pointing
after the last character.
Floats are another source of errors, due to some using hexadecimal
notation, and others using binary and still others some form of excess
twos notation. Between them round off and truncation errors can occur
at intervals of 38, 72 and 134 if I remember correctly, at least
something like these intervals where the rounding function will produce
one number in one implementation and a different number in another. I
have had people argue with me about my code being wrong, even after I
would write a test case and show them that the problem wasn't the code,
but rather the choice of compiler and its resultant choice of floating
point implementation.
Quite possibly your code was wrong.
With floating point, deciding such things can be a bit tricky.
C89 doesn't require much of floating point.
if(x/11.0==13.7) { ... } would almost certainly be wrong.
There might be compilers and hardware for which
it would do what you want with your data,
but that wouldn't mean the code wasn't wrong.
if(x< 150.7) { ... } might be good.
It gets more arcane with chained calculations. Each time you multiply
two numbers together, there is an associated rounding error. But it is
But how would you categorize all these different effects, provide
examples, show the results in the several cases and also hopefully add
some guidance (such as man pages do) for the combinatorial effects?
With difficulty.
One has to live with the fact that floating point
arithmetic is not real number arithmetic.
One will sometimes have to deal with cases too close to call.
Really good code will detect them.
It's not easy.
--
Michael hennebry@xxxxxxxxxxxxxxxxxxxxx
"Pessimist: The glass is half empty.
Optimist: The glass is half full.
Engineer: The glass is twice as big as it needs to be."
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
