Jeremie Pelletier wrote:
Don wrote:
Saaa wrote:
Jeremie Pelletier wrote
Saaa wrote:
I think is very bug-prone, isn't it obvious iub should be -5?
ubyte ub = 5;
int iub = -ub; // iub now is 251
What is the reasoning to do it this way?
Minus toggles the most significant bit, be it on a signed or
unsigned type. When converting it to an int, the byte being signed
or unsigned does make a difference: when unsigned the number is
copied as is, when signed the most significant bit (bit 7) is
shifted to the most significant bit of the int (bit 31).
Its therefore pretty standard logic, no warning is given since the
entire ubyte range fits within an int
Jeremie
Thanks, but it is not that I do not know how it occurs more that
I should have asked whether people use this kind of logic.
For me it resulted in annoying bug like this:
for(int i = nloop;i<10;i++);//ubyte nloop is created quite a few
lines above.
This has been discussed before, and it really should be an error.
It's reasonable to implicitly cast between integral types of different
size, and also signed<->unsigned, but performing both within the same
expression is almost always a bug. It should not be possible without
an explicit cast.
I know VC++ shouts a warning everytime signed and unsigned integrals are
mixed, maybe that's the road D should take too.
We can do *much* better than that.
About two releases ago D2 got integer range tracking, so you can do
things like:
long a = someCrazyFunction();
ubyte b = (a & 7) | 0x60; // No worries! This is perfectly fine!
ubyte c = a; // Error, might overflow.
It just needs to be extended a bit more. It's far from finished.
