-
Notifications
You must be signed in to change notification settings - Fork 222
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BUG: Add test showing how downcasting to CFArray is unsound #158
Conversation
I pushed another test, showing how this problem originates at CFArray<X>::instance_of::<CFArray<Y>>() Does return true in all cases. |
Casting a CFArray to a particular CFArray needs to be unsafe. I'm not yet sure how fix downcast. |
If we add a trait that's ConcreteCFType that non-generic CFTypes implement. We can make downcast become pub fn downcast<T: ConcreteCFType>(&self) -> Option<T> { and then we'd have |
I've put up a fix in #159 |
Add appearance names <!-- Reviewable:start --> This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/cocoa-rs/158) <!-- Reviewable:end -->
We could potentially turn this into a doctest that verifies that it doesn't compile? |
@jdm How do you create a test that passes if it does not compile? |
See https://doc.rust-lang.org/beta/rustdoc/documentation-tests.html
|
Updated the test to be a |
@bors-servo r+ |
📌 Commit 6c63acc has been approved by |
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 -->
☀️ Test successful - status-travis |
The |
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 aCFType
and then down to aCFArray<Y>
for anyY: TCFType
. It never checks that the elements in the array are of typeY
or not. At this pointCFArray::iter
will happily give out&Y
references, while in fact the pointers backing those objects are pointing toXRef
instances. So doing anything with the&Y
will likely cause invalid memory access.How do we solve this?
Ping @jrmuizel
This change is