assigning a negative num to unsigned var

[srvaldez]

it appears that FB is happy to assign a negative value to an unsigned variable without warning, is there anyway to get a warning?

[MrSwiss]

No, I don't think so. I've already criticized this behavior, but nobody seems to care.
Some even find it "great" to assign -1 to a Unsigned variable ...

[xlucas]

Is this true even when assigning a negative at compile time? I can see a point in not performing this check at run time. It'd be an implicit conversion just like when you assign a Long to a Short or a Short to a Double, but there would be no penalty if the check were made at compile time on explicit assignations. I agree that it'd be better to have a warning there.

[srvaldez]

Is this true even when assigning a negative at compile time?

yes, it would be nice to get a warning similar to what one gets when passing different pointer types.

[xlucas]

Uhm... I assume then the opposite must also happen, like:

Code: Select all

Dim a As Byte
a = 255
Print a

... and you get -1

Indeed. That's what I'm getting!

[sancho2]

Uhm... I assume then the opposite must also happen, like:

Code: Select all

Dim a As Byte
a = 255
Print a

... and you get -1

Indeed. That's what I'm getting!

You are getting exactly what is expected.
This is documented:

Code: Select all

8-bit signed whole-number data type. Can hold a value in the range of -128 to 127

That code is no different then assigning a = &HFF, which of course has no overt signage and its decimal equivalent is determined by the variable type and its limitations.
Exchange byte with UByte and you get 255 because it falls in the range of the UByte variable.
I agree that a compile time warning would be helpful. In this case (as opposed to assigning a negative decimal to an unsigned variable) is it really warranted?

[xlucas]

My personal opinion is that this is not a serious issue. Yet, I do agree with Sr. Valdez that it would be even better if a warning were issued.

I believe it is not serious because the really problematic cases are those in which a variable is assigned and one does not know the overflow has occurred. In those cases, there's nothing the compiler can do, and an overflow detection system would have an unacceptable impact of the performance, as it would have to be done at run-time. When a constant is assigned, (the cases in which something can be done), it is always very easy to see what is going on.

On the other hand, I agree with Sr. Valdez because, semantically, we have to admit you can't assign -1 to an unsigned variable or 255 to a signed byte. Not displaying a warning is likely not serious, but is "less correct" than displaying it and, in the rare event that one would not realise of the type mismatch, the warning would help.

[counting_pine]

I think we decided that the checks would add too much complexity internally, and it wasn't always clear what should trigger a warning and what shouldn't.

Code: Select all

dim as long n
n = 2147483648 '' overflow - should warn
n = 32768 * 65536 '' overflow - should warn
n = &h80000000 '' shouldn't warn?
n = 1 shl 31 '' should warn?

I guess with decimal constants, it's always clear what the signedness should be, but with hex values, or with bitwise math, it isn't always clear.

The big problem is that all these constants evaluate to the same value (in 32-bit mode), so the compiler can't necessarily tell them apart when doing the assignment step.