When auditing this crate to incorporate it into a project, I found issues around CFStringRefs being over-released in certain circumstances when creating *-Property structs using ::new().
The problem would arise when using an incorrect user-supplied string when initializing a property, making the following line of code result in a panic with a SIGILL:
let name = destination.get_property_string("NotARealPropertyName").unwrap();
So when boiled down, the problem is basically the same one as in https://github.com/chris-zen/coremidi/issues/17 - a CFString was created and then immediately dropped in -Property::new(), meaning any CFStringRefs created from it are now invalid. The solution was to abstract over -Propertys now owning a CFString or a CFStringRef, depending of if the Property struct was initialized with a constant from CoreMidi or a user-supplied string. This is what the PropertyKeyStorage struct does.
When auditing this crate to incorporate it into a project, I found issues around
CFStringRefs being over-released in certain circumstances when creating *-Propertystructs using::new().The problem would arise when using an incorrect user-supplied string when initializing a property, making the following line of code result in a panic with a
SIGILL:So when boiled down, the problem is basically the same one as in https://github.com/chris-zen/coremidi/issues/17 - a
CFStringwas created and then immediately dropped in -Property::new(), meaning anyCFStringRefs created from it are now invalid. The solution was to abstract over -Propertys now owning aCFStringor aCFStringRef, depending of if thePropertystruct was initialized with a constant from CoreMidi or a user-supplied string. This is what thePropertyKeyStoragestruct does.