man 3 switch

[Michael Hennebry]

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 at web.cs.ndsu.NoDak.edu
"Pessimist: The glass is half empty.
Optimist:   The glass is half full.
Engineer:   The glass is twice as big as it needs to be."