A number of callback functions associated with the CFRunLoop types are
allowed to be NULL to evoke default behavior.
Prior to this commit the definition of those structs prevented passing
in null which meant resorting to transmute or other tricks to
effectively set null, but with recent compiler versions the compiler
emits `ud2` instructions and triggers a fault at runtime.
The correct resolution for this is to define these fields as `Option`al
callbacks and that is what this commit does.
I've used this approach successfully here in another project:
Refs: https://github.com/wez/wezterm/commit/398f333c32fb1ff4ccd9cc001a66ae22522eb60c
I've bumped up the version for the crate as part of this commit
because it effectively changes the API around these structs.
Begin documenting core-foundation macros.
I started doing this after talking through some issues with @raphlinus. Clearly more to do, but would like to get this in sooner rather than later.
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/core-foundation-rs/297)
<!-- Reviewable:end -->
These transmutes were going from one type of pointer to another,
and so can be done as casts instead.
Doing so also means that one unsafe block can be removed.
This was found via clippy.
BUG: Add test showing how downcasting to CFArray is unsound
This PR is not intended to me merged directly. It adds a test that causes undefined behavior without using `unsafe {}`. So it's more to show the problem and discuss a solution.
The problem here is that if you have a `CFArray<X>` you can cast it up to a `CFType` and then down to a `CFArray<Y>` for any `Y: TCFType`. It never checks that the elements in the array are of type `Y` or not. At this point `CFArray::iter` will happily give out `&Y` references, while in fact the pointers backing those objects are pointing to `XRef` instances. So doing anything with the `&Y` will likely cause invalid memory access.
How do we solve this?
Ping @jrmuizel
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/core-foundation-rs/158)
<!-- Reviewable:end -->
Using some more macro magic we can avoid having to duplicate
our impl macro implementation for generic types. This will help
when we want a version for CFDictionary with two type parameters.
Reduce usage of libc crate.
Switch from using `libc` types to `::std::os::raw`. This is a breaking
change due to the differences in how `c_void` is defined.
`core-foundation-sys` no longer needs the `libc` dependency.
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/core-foundation-rs/156)
<!-- Reviewable:end -->
Switch from using `libc` types to `::std::os::raw`. This is a breaking
change due to the differences in how `c_void` is defined.
`core-foundation-sys` no longer needs the `libc` dependency.
Wez Furlong
