So, the solution for my previous blog post about the borderline integer was to use simply an unsigned integer. However, even such a simple change may have some more unexpected results. Or maybe not even possible?

The Java language actually leaves out unsigned types. It’s not a big deal, but there are a few cases which may be slightly problemous, such as the previously mentioned borderline integer. And it is kind of annoying to have bytes in range -128..127 (easily fixed to 0..255 by anding with 0xff and assigning to int). But anyway, let’s move to the actual reason why I wanted to write this post.

Recently I had to fix some bug caused by combination of unsigned ints and floats. Consider the following code:

unsigned int u = 3;
float f = -u;
// and next just do something with f
// ...


Looks pretty simple and innocent, doesn’t it? Just take a value, negate it and put to a float and then use it. Well, let’s add this following code to check out, including an integer version of the negated value just for comparison:

int i = -u;
printf("%f\n", f);
printf("%d\n", i);


And when we run that, we get the following printed as the result:

4294967296.000000
-3

Pretty amazing — and not quite what you expected?

This particular result felt kind of illogical to me. But when thinking about the reason for such behavior, I guess it once again boils to the fact that the negate operator just works at the bit level and doesn’t care if the type is signed or unsigned, which is like syntactic sugar, so to say. Then I thought that maybe compiler should magically notice what’s going on and make the result of -value a signed integer.

On the other hand, it still makes sense that the type stays the same, when thinking about some other examples such as constant-var or var1-var2. Well, I’m not sure if it makes sense or not, but at least this makes it a bit easier to understand why there isn’t some implicit signedness conversion added. :-) So in any case, the intermediate result is that the negation of unsigned value ends up being unsigned, i.e. most likely a large value counting down from (unsigned int)~0. And then the end result is that value converted to float, as seen in the example.

I haven’t bothered to check from C89/C99 standards if they have something to say about this thing. And before you shout that the compiler will warn you, it actually might not. Of the above example, if you use at least warning level 2, Visual C++ will happily tell you warning C4146: unary minus operator applied to unsigned type, result still unsigned. But GCC won’t say anything even with -Wall -ansi -pedantic!

I’m curious to know if it would actually break something if there would be some sort of automatic/silent switch to signed int from unsigned int in cases like that, except in cases where the result value is put back to an unsigned int. Any thoughts are welcome.

Sometimes one finds a weird bug which “shouldn’t happen” but still does. And after more or less tedious debugging session the bug is found, and analyzing it shows it’s probably quite logical why the thing happened after all.

Even if it may be stressful to try find such nasty problems, in the end I’m usually fascinated by such weird minute details. Here is one such finding.

For this one I’ll present just the pure problem without a “solution” first, which I’ll add later. Feel free to add a comment and describe what you think — this one is actually really obvious.
Read the rest of this entry »