Protect against overflows in BoxedFlagValues by huwr · Pull Request #109 · unsignedapps/Vexil

huwr · 2023-03-17T01:32:37Z

📒 Description

Previously, attempting to unwrap an Int from a BoxedFlagValue into an FlagValue that was not wide enough would cause a runtime error.

Now, we unwrap the Int from the BoxedFlagValue and convert it into the Int type’s fallible initialiser. That way, we know it will not be too big when we do the assignment.

🗳 Test Plan

Unit tests included for all Int types (except Int64, which is a little harder)

✅ Checklist

I've added at least one test that validates that my change is working, if appropriate
I've followed the code style of the rest of the project
I've read the Contribution Guidelines
I've updated the documentation if necessary

😠 Not finished

It's not finished. Somehow, there's double-optionals are making it into the UserDefaults FlagValueSource's set value function.

 /// Sets the value for the specified key
publicfunc setFlagValue<Value>(_ value:Value?, key:String)throwswhere Value:FlagValue{guardlet value = value else{ // unwraps a UInt16?? to UInt16? It must be `.some(nil)`
self.removeObject(forKey: key)return}self.set(value.boxedFlagValue.object, forKey: key) // tries to send nil `UInt16?` in here, which fails.
}

I shall ponder because I'm not sure why they're double-optionalised now.

Previously, attempting to unwrap an Int from a BoxedFlagValue into an FlagValue that was not wide enough would cause a runtime error. Now, we unwrap the Int from the BoxedFlagValue and convert it into the Int type’s fallible initialiser. That way, we know it will not be too big when we do the assignment.