Swift Boolean value <invalid>

Asked 15/12, 2016 at 20:45 Answered 14/9, 2017 at 10:2

The attached screen shot says it all: I have a valid true Bool, I negate it with the bang operator, and (Xcode tells me) I have an invalid value.

It appears that this "invalid" value does behave as if it were false. But really, wtf?

Sonority answered 15/12, 2016 at 20:45 Comment(10)

The memory for that bool either was never initialized, or has been corrupted in some way. The only valid values for Bool are 0x01 (true) and 0x00 (false) – Honesty 15/12, 2016 at 20:51

The Xcode debug window shows clearly that the bool was initialized. That's what line 72 does. Moreover, the enabled value can't be optimized out since it is used on line 73. However, this could just be an Xcode debugger bug... – Sonority 15/12, 2016 at 20:59

I suspect this code has been edited since the debugging session was started, and that the code doesn't reflect the state of the program – Honesty 15/12, 2016 at 21:0

On a side note, this is could be so much more simply written as adFreeButton.isEnabled = !PurchaseState.isAdfree – Honesty 15/12, 2016 at 21:1

The code was not edited since the debugging session was started. And yes, I did originally have the code as you suggested. I rewrote it in this way so that you could see clearly that !true did not equal false. I've been writing code now for 40 years; I do understand booleans. – Sonority 15/12, 2016 at 21:14

Easy there, no need to get defensive lol – Honesty 15/12, 2016 at 21:29

This is really strange behaviour. Could you try to write a minimal, complete, and verfiable example? – Honesty 15/12, 2016 at 21:30

Why couldn't enabled be optimized away even if it's used? Can't it just get replaced, depending on the optimization level? – Stoical 15/12, 2016 at 21:35

Andreas' comment could be the answer. FWIW the most minimal example, i.e. in a Playground, does not exhibit the behavior. I will see about trying to create an example, but as per Andreas, this might be very context-sensitive. – Sonority 15/12, 2016 at 22:29

I'll just put it in an answer then – Stoical 16/12, 2016 at 18:15

I've had this issue in Xcode 8.3.1 and Swift 3.1 https://github.com/onmyway133/notes/issues/278

I tried

Clean build folder and delete derived data folder
Delete the app
Reset simulator
Restart Xcode
Restart Mac

But does not work. The workaround is to

let enabled = disable ? false : true

Glossematics answered 10/5, 2017 at 10:34 Comment(0)

I'm no LLVM expert but I wouldn't be surprised about this behavior at all, unless optimization is set to Onone in which case it should have left your code alone. The intermediate variable is just asking to be optimized away, after all.

Stoical answered 16/12, 2016 at 18:14 Comment(5)

However (and i should have specified this) both enabled and disabled are used several times later in the method. (This is part of why I have both enabled and disabled defined: the code reads better and it is harder to inadvertently omit a bang negation symbol.) In fact, the debugger is paused at precisely one of the places where the (apparently bogus) value is being used. Finally, in debug mode, my optimize setting is -Onone. – Sonority 16/12, 2016 at 20:31

I also declare variables liberally, but no matter how much I use them I still expect them to disappear and get replaced by something much better. If your screenshot is in fact from a debug run, which you are implying, then I'm afraid you'll have to wait for someone more knowledgeable. – Stoical 16/12, 2016 at 20:51

I agree that the compiler is free to rearrange local variables if provably correct. (I'm a compiler writer. You'll sympathize with the number of times I have had to explain to students that "No, fewer locals does not mean more efficient code.") But yes the screenshot is of the Xcode debugger. Could be a harmless bug in the Swift runtime. Harmless because 0xfe (aka -2) was indeed handled as false by the control flow. – Sonority 16/12, 2016 at 21:17

I think you misunderstand what I mean by debug run — it's not a question of whether the screenshot is of the debugger, but rather which build configuration is used when running from Xcode. debug config (with Onone) is default, but not necessary. – Stoical 16/12, 2016 at 21:25

I see. It was the debug config with -Onone. – Sonority 17/12, 2016 at 4:36

Got the same issue, with correct value for add code like print(theBoolValue).

But when use p in swift command line. Or just check the value in debug stack, the value become <invalid>(Oxfe).

Freddiefreddy answered 14/9, 2017 at 10:2 Comment(0)

Recommended topics

Hot tags