Missing null checks

[roblabla]

In the core-foundation crate, there appears to be a lot of functions missing NULL checks in the allocation, potentially causing segfaults when trying to over-allocate (instead of panicking or returning a Result). Examples include dictionary creation, array creation or string creation. Those functions can all return NULL according to Apple's documentation (e.g. see return value doc here

It would seem wise to add some railguards against this somewhere - perhaps wrap_under_create_rule should have an explicit NULL-check, causing a panic if it is encountered?

[jdm]

Asserting inside wrap_under_create_rule sounds like a useful first step.

[roblabla]

Another potential source of problem is in CFDictionary::get. It returns an Option, either None if the key is not found or Some otherwise. But even if a value is found, it may be null!

Furthermore, CFMutableDictionary has a couple soundness holes. Take the following compiling program:

#[test]
fn this_is_very_ub() {
    let dict: CFMutableDictionary<CFString, CFString> = CFMutableDictionary::new();
    let mut dict_untyped = dict.to_untyped();
    let test = CFString::new("test");
    dict_untyped.add(&test.to_void(), &std::ptr::null());
    let val = dict.get(&test);
    println!("{}", val.char_len());
}

This can cause an UB in one of two ways:

• CFDictionary internally calls various functions on the value pointer (those are passed as callbacks to the CFDictionaryCreateMutable, core-foundation gives the default values). Having the ability to pass null or even arbitrary pointers can easily cause the internal Core Foundation functions to segfault or otherwise UB. In particular, the add function will call CFRetain on the null pointer and cause a crash.
• Even if those functions weren't a problem, the to_untyped() function allows creating CFString (or otherwise) from an arbitrary pointer.

EDIT: Split into #362

[roblabla]

Thinking about this some more, I think a lot of the current collection wrappers are unsound. Most of them (NSArray, NSDictionary, NSSet) expect their arguments to be relatively well-formed, so you simply cannot safely allow the user to pass arbitrary pointers to it. In practice, only NSDictionary is affected since it's the only collection with mutation implemented.

---

Yet another soundness hole: CFArray::from_copyable is really, really wrong, as it allows reading uninitialized memory.

#[test]
fn this_is_very_ub() {
    let arr = CFArray::from_copyable(&[1u8; 2]);
    assert_eq!(arr.get_all_values(), vec![1 as _, 1 as _]);
}
// thread 'array::tests::this_is_very_ub' panicked at 'assertion failed: `(left == right)`
//  left: `[0x600000101, 0x500000000]`,
// right: `[0x1, 0x1]`', core-foundation/src/array.rs:290:9

This is because CFArray can only hold pointer-sized values, but from_copyable allows filling it with any data that implements Copy, no matter the size. I can imagine this causing some really nasty bugs.

Not to mention, I suspect the very idea behind this API to be wrong, as again, CFArray really expects valid pointers to be inside. But that's not readily exploitable from the current API surface afaict.

EDIT: Just realized this is #291