flagging unsigned subtraction assigned to bigger signed number?
Walter Bright
newshound2 at digitalmars.com
Wed May 21 18:19:19 UTC 2025
Some good arguments. But it comes down to a value judgement against competing
interests.
The `if (cond);` has no useful purpose, and so making it illegal is a
no-brainer. I'm surprised that the C/C++ Standard still hasn't at least
deprecated it.
An unsigned type is of less utility in a language like Java that is not a
systems programming language (trying to make a memory allocator with no unsigned
types is going to wind up pretty ugly). But, people still fake unsigned types
and use them.
I, too, have found that the prohibition of `if (a = b)` has been of benefit,
with pretty much zero downside. Such a construction, even if intended, will
always look suspicious, so professional code should eschew it.
While you are correct that `(messages.length - i)` will never wrap, as you wrote
any subtraction in unsigned math has the potential for wrapping, here it is the
`600 -` that's doing it. I've been programming for a very long time, and
reflexively double check any subtractions (particularly in for-loops that count
down to zero), and any < <= > >= comparisons. They're all potential
signed/unsigned bugs.
There are a lot more signed/unsigned interactions than just subtraction.
Addressing one means what about the others? Do we really want to flag a
conversion from unsigned to floating point?
Back in 1989 when the first C standard was being developed, half the existing
compilers used "sign preserving" integral conversions, while the other half used
"value preserving". Couldn't have both, one set of compilers was going to lose.
But never on the table was getting rid of mixed signed/unsigned expressions.
They were too valuable. (Value preserving was selected.)
Another factor is I've used languages that required explicit casting to use
mixed signed/unsigned. I understood the reasoning behind it. But it was just
unpleasant and the code looked ugly. Just not worth it.
P.S. this is one of those perennial topics that regularly comes up.
More information about the Digitalmars-d
mailing list