GNOME Bugzilla – Bug 608434
Strange nullable boolean condition results
Last modified: 2010-01-29 16:34:51 UTC
I'm not sure if it is a bug or a feature, but I'll post it anyway. I hope it helps. When I try to run the following code: int main(string[] args) { bool? x = false; bool? y = true; bool? z = null; if(x) print("X!\n"); if(y) print("Y!\n"); if(z) print("Z!\n"); return 0; } I get "X! Y!", but I would expect to see only "Y!" there. By the same way, when I try to run the following code: int main(string[] args) { bool? x = false; bool? y = true; bool? z = null; if(x == true) print("X!\n"); if(y == true) print("Y!\n"); if(z == true) print("Z!\n"); return 0; } I see an "Y!" and then a segmentation falt message when the if(z == true) is done. If this isn't a bug, so the right way to check it would be by using two conditions? I mean, something like: if(z) { if(z == true) { // ... } } Thank you all.
Both of your problems are bugs IMO. In the first case, a pointer to the value (which is the way nullable's are implemented) seems to be checked instead of the value. In the second case, null case should be handled implicitly by the equality operator. Using two conditions seems to be a good workaround, as long as you check for the value being true. If you checked for false that way, fix would break it.
Ah, no, fix wouldn't break it. It's good, I just didn't have any coffee yet today. :) You can also collapse it as: if (z && z == true) { since Vala does lazy evaluation here.
Ah, sorry, fix WOULD break it if false was there. Sorry for the noise, gonna get my coffee.
Yes, both problems are bugs. Please note that a crash on if (z) in the first test case is expected with the two bugs fixed, though, as that's a null dereference.
commit 61b2284b443e8c7a442abdabc937438dd6fea5de Author: Jürg Billeter <j@bitron.ch> Date: Fri Jan 29 15:13:24 2010 +0100 Convert conditions in if statements to bool if necessary Fixes part of bug 608434.
if (z) in the first case is expected to trigger a compiler error, because it's not an expression of type "bool".
bool? is implicitly convertible to bool, so this doesn't trigger a compile-time error and this is intentional. Otherwise, if (x) and if (y) would need to trigger the error as well as they are not an expression of type "bool", either.
> Otherwise, if (x) and if (y) would need to > trigger the error as well as they are not > an expression of type "bool", either. Yes, that's what I was thinking. I think having to explicitly compare nullable bool to true is not that much of an inconvenience compared to a segfault. Hovewer, I guess this is going to be fixed later, when strict null checking becomes more serious, right? Still, I think there should be at least a warning that using bool? directly is unreliable and can be ensured by equality checking.
If we're consistent, there should be no warning here as we currently don't do strict non-null checks and therefore don't have warnings like that in similar situations, either.
commit 5a597f879078b5785489dfcaa316b78bae033bcc Author: Jürg Billeter <j@bitron.ch> Date: Fri Jan 29 17:23:29 2010 +0100 Support equality checking on nullable boolean and numeric types Fixes bug 608434.