Each CFFoo has exactly one CFFooRef and which one is defined by CFFoo, not by its user. Thus the type of reference can be an associated type instead of a generic.

As you can see this greatly simplifies things such as calling instance_of and from_CFType_pairs as well as using CFPropertyListSubClass. It basically removes one generic parameter from any method dealing with TCFTypes in some way.

This is a breaking change, so it would probably mean a 0.5.0 release if accepted. I don't know what your stance on breaking changes or version bumps is, so I don't know if you want this or not. But it would simplify the API, both here, but first and foremost in higher level crates using this.

This change is 

All the FFI functions have fancy types now and use references instead of raw pointers for arguments.

Now, a CFRef<T> value represents a refcounted value to be released on Drop, CFShared<T> represents a shared value that can be retained to produce a new CFRef<T> (this will be a useful distinction for mutable types, where a bare T shouldn't be retainable to keep unique ownership).

To simplify things and avoid either having wrappers of wrappers of all methods behind traits, I put the safe and thin methods directly on the opaque FFI types.

Let's begin the infinite bikeshedding!

This change is

There are a lot of places where we increment and decrement the retain count when we would not have to. For example, a very common use-case with PropertyLists is to just directly cast them to their correct sub type and then throw the PropertyList away (because there is nothing you can do with the PropertyList instance directly.)

The reason we do this, I guess, is mostly because all Drop implementations force a retain count decrement. So we have to keep incrementing it to keep it correct. But if we add a flag to types that can be used to disable the decrement, then we can also get rid of the increment when we virtually just want to cast a pointer between two types.

This PR implements this by adding a boolean flag to all CF structs that is used by the Drop impl to determine if it should CFRelease the instance or not. Then this flag is modified in appropriate places where we cast to other types and consume ourselves.

I added some benchmarks locally. I did not want to commit them since benchmarking only works on nighty, and I did not feel like adding a feature flag for it etc. Anyhow, the following benchmarks:

#[bench]
fn bench_before(b: &mut Bencher) {
   let string = CFString::from_static_string("Bar");
    b.iter(|| unsafe {
        string.clone()
            .to_CFPropertyList()
            .downcast::<_, CFString>()
            .unwrap()
            .disable_release();
    })
}

#[bench]
fn bench_after(b: &mut Bencher) {
    let string = CFString::from_static_string("Bar");
    b.iter(|| unsafe {
        string.clone()
            .into_CFPropertyList()
            .downcast_into::<_, CFString>()
            .unwrap()
            .disable_release();
    })
}

Given the following results:

test propertylist::test::bench_after         ... bench:          16 ns/iter (+/- 3)
test propertylist::test::bench_before        ... bench:          73 ns/iter (+/- 14)

The final call to disable_release() in the benchmarks are to prevent the type coming out of the unwrap() from calling CFRelease on drop, and thus avoid measuring that. I want to try to measure only {to,into}_CFPropertyList, downcast and downcast_into. The clone is needed because the into version requires it and it would then not be fair to not have it on both.

I would say that speeding it up by a factor of ~4 can be well worth it? (Well, that 4 is of course no good measurement of anything, microbenchmarks etc. etc.. The benchmark mostly shows that a lot can be gained from avoiding some retain counting.)

This change is 

Added CFMutableDictionary that presents the mutable dictionary functions of CF. Tries to present a similar interface as CFDictionary.

Fixes issue #93.

This change is 

This problem was found when I tried to debug #132

But since that PR grew so large, and this fix was very unrelated to the work in that PR I split it out to a separate one.

This change is 

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

This change is 

This patch allows build errors like https://buildd.debian.org/status/fetch.php?pkg=rust-core-foundation&arch=arm64&ver=0.6.1-1&stamp=1533301991&raw=0 to go through on architectures that use u8 as c_char.

This change is 

I'm needing these CFSet functions for some USB HID interactions with IOKit, so here's the external references.

They are defined in CoreFoundation:

• CFSetApplyFunction and
• CFSetGetCount

This change is 

This pull request:

• removes two unnecessary casts (from CFIndex to usize and back again)
• extracts the to rust string conversion: instead of doing it on-the-fly in the Display implementation (and thus only supporting the indirect ToString way to get a rust string from a CFString, which always allocates) this implements From<&CFString> for Cow<str> allowing everyone the possibility of avoiding an allocation if the CFString is already formatted in UTF-8.

In #453, @pmj proposed bare-bones contribution guidelines, which were received favorably by @jrmuizel. This pull request insert's @pmj's proposed text into the top-level README.

Currently, due to a quirk in Rust's type inference interacting with the structure of the msg_send! macro, a () return type will be inferred when the compiler cannot otherwise determine the return type. This behavior is expected to change, and in the future could resolve to a ! return type, which results in undefined behavior.

Linting has previously been added for this in rust-lang/rust#39216, but it did not catch these cases due to SSheldon/rust-objc#62. An upcoming version of objc will be fixed to stop hiding these errors, at which point they will become compile errors.

This change fixes these errors and allows cocoa to compile with the fixed version of objc.

I'm working with Rust and Core Foundations and I'd like to know if the code looks right or if it has some flaws or if I can make it simpler

use core_foundation::base::{FromVoid, TCFType, TCFTypeRef, ToVoid};
use core_foundation::dictionary::{CFDictionary, CFDictionaryRef};
use core_foundation::string::CFString;
use core_graphics::window::{copy_window_info, kCGNullWindowID, kCGWindowListOptionAll};
fn main() {
    let windows_info = copy_window_info(kCGWindowListOptionAll, kCGNullWindowID).unwrap();
    for window_info in windows_info.get_all_values() {
        let key = CFString::from_static_string("kCGWindowName");

        let winfo_hash: CFDictionary =
            unsafe { TCFType::wrap_under_get_rule(window_info as CFDictionaryRef) };

        let window_name = winfo_hash.get(ToVoid::to_void(&key));

        let window_name: String =
            unsafe { CFString::from_void(window_name.as_void_ptr()).to_string() };

        println!("{:?}", window_name);
    }
}

Is that right? or do we have a "simpler" way of doing that? My goal is to take a screenshot of the window app if t matches some criteria

Thanks in advance.

This PR adds explicit permissions section to workflows. This is a security best practice because by default workflows run with extended set of permissions (except from on: pull_request from external forks). By specifying any permission explicitly all others are set to none. By using the principle of least privilege the damage a compromised workflow can do (because of an injection or compromised third party tool or action) is restricted. It is recommended to have most strict permissions on the top level and grant write permissions on job level case by case.

https://developer.apple.com/documentation/appkit/nsalert?language=objc

This is for modal dialogs. Would be convenient to have rust wrappers for setMessageText, showsSuppressionButton, etc. and for reading the result.

Just hit this build error when I added wry to my app:

error[E0432]: unresolved import `core_foundation::mach_port`
 --> /Users/adamfreeman/.cargo/registry/src/github.com-1ecc6299db9ec823/core-graphics-0.22.3/src/event.rs:4:5
  |
4 |     mach_port::{CFMachPort, CFMachPortRef},
  |     ^^^^^^^^^ could not find `mach_port` in `core_foundation`

error[E0433]: failed to resolve: could not find `mach_port` in `core_foundation`
  --> /Users/adamfreeman/.cargo/registry/src/github.com-1ecc6299db9ec823/core-graphics-0.22.3/src/sys.rs:32:44
   |
32 |     pub type CGEventTapRef = core_foundation::mach_port::CFMachPortRef;
   |                                               ^^^^^^^^^ could not find `mach_port` in `core_foundation`

trivial MR to fix this one, just update the dependency to 0.9.2 or 0.9.3, but there's probably more like this, and it may be worth adding something like https://crates.io/crates/cargo-minimal-versions to the CI to catch these in the future.

Hello, since this commit cocoa-foundation went to 0.1.1, but its version hasn't been updated in cocoa Cargo.toml yet.

@jrmuizel could you please check and release a new version if ok? Thanks.

Of particular note:

• libc is not needed in most cases, one can simply use std::os::raw
• leaky-cow seems like it existed to work around compiler limitations, these are no more

@jrmuizel I've included version bumps in here as well, would be nice if you could also do a new release after this