On 5 Dec, Sven Neumann wrote:
> if we'd use a programming language that would properly support ranged
> types, it'd be a cleanup. C however doesn't assure that. If the
> program would throw a signed exception if a negative value is ever
> assigned to an unsigned variable, we'd indeed be able to catch bugs
> and declaring variables as unsigned would make sense. Since this is
> not the case, the use of unsigned variables is dangerous without
> giving any real advantages.
FWIW it might be possible to get this behaviour in future versions of
gcc.
> you can't have tested all possible usage patterns since there are way
> too many.
Right, but at least the a gross part functionality works so it can't be
as broken as you're suggesting.
> the point is: how are we supposed to catch them? If the compiler would
> give us hints like it does for wrong usage of consts and enums, great.
> However, this is not the case unfortunately.
You're wrong here. The latest versions of gcc have a vast number
of checks that are useful here, just to copy a few from the source:
"integer overflow in expression"
"large integer implicitly truncated to unsigned type"
"negative integer implicitly converted to unsigned type"
"overflow in implicit constant conversion"
"comparison is always false due to limited range of data type"
"comparison of unsigned expression >= 0 is always true"
"right shift count is negative"
"right shift count >= width of type"
"comparison between signed and unsigned"
"comparison of promoted ~unsigned with constant"
"comparison of promoted ~unsigned with unsigned"
"signed and unsigned type in conditional expression"
"cast to pointer from integer of different size"
"overflow on truncation to unsigned integer"
"overflow on truncation to integer"
"comparison is always %d due to width of bitfield"
Just a quick grep and cut&paste action from a messages that might be
related to this topic. Of course this will only catch obvious problems
but then again I have some ideas to get even stricter checking.
> distances are a good example since they can very well be negative:
> dist = a - b;
That's a bug. Correct is abs (a - b).
> this perfectly valid code will awfully break if b is larger than a
> and dist is defined unsigned.
Yes, it will.
> For the CPU and the compiler it wouldn't make any difference, only the
> outcome would be wrong.
That's correct, if it really is desired to have negative distances to
also encode the orientation then "dist" would have to stay signed and be
documented so.
> then have a look at some of the bugs reported in plug-ins lately. They
> have been reported years after the first release and didn't get caught
> because they only showed up when the plug-in was used on small images
> (width < 64 || height < 64). Such a bug could very well be caused by
> the use of an unsigned variable.
That's a wild speculation. I'm just surprised that the reporter didn't
seem to mention that the the images were below some size because that
would have made tracking a bug trivial but that's a different issue.
--
Servus,
Daniel
