🚀 go-pugleaf

In article <1992Sep28.162422.26386@sics.se> uddeborg@sisu.se (Goeran Uddeborg) writes:
>>>If the function was 'unsigned int' then the result would ALWAYS fit...
>>It would make sense.  Unfortunately, that's not the way abs() was defined
>>originally... and changing it now might break a lot of code.
>
>It could hardly break a lot of code, could it?  The change would
>increase the domain of the abs() function by one value.  Nothing that
>worked previously would stop working...

You've missed the point.  The problem is not that one extra return value
has appeared, but that *the type of abs() has changed*.  Worse, its
signedness has changed, which puts you squarely into the fever swamp
of mixed-signed-and-unsigned expressions.  I try to avoid thinking about
that stuff, so I can't cite detailed examples off the top of my head, but
I know it's a minefield.  (It's also an area where there are already
substantial portability problems, because compilers differed.)

>... (Unless somebody actually
>depend on abs() returning a negative value for one particular input
>value, but do they really want to protect that kind of code?  Is it
>even defined that way in the standard?)

ANSI C says "if the value won't fit, result is undefined".  This boils
down to "you cannot safely call abs() with that argument".
-- 
There is nothing wrong with making      | Henry Spencer @ U of Toronto Zoology
mistakes, but... make *new* ones. -D.Sim|  henry@zoo.toronto.edu  utzoo!henry