Skip to content
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

WIP Feature/nng 1.2 #18

Merged
merged 29 commits into from
Jan 7, 2020
Merged

WIP Feature/nng 1.2 #18

merged 29 commits into from
Jan 7, 2020

Conversation

jeikabu
Copy link
Owner

@jeikabu jeikabu commented Apr 8, 2019

Fixes for nng master@HEAD what will become v1.2

@jeikabu jeikabu requested a review from neachdainn April 8, 2019 07:43
@neachdainn
Copy link
Collaborator

Glancing over it, it looks good to me. I'll double check it against Nng-rs later tonight.

Copy link
Collaborator

@neachdainn neachdainn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This version uses nng_pipe_ev instead of c_int in several places, such as nng_pipe_notify, which I think is a very good change. However, the nng_pipe_ev::try_from function should be updated to take an nng_pipe_ev instead of an i32.

Other than that, it looks fine to me. If you want to merge without making the change, I won't complain.

@@ -45,6 +45,7 @@ source-update-bindings = ["build-bindgen"]
cty = {version = "0.2", optional = true}

[build-dependencies]
version_check = "0.1"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't know about this crate. It seems pretty cool - I'll have to look into it for my own projects.

@neachdainn
Copy link
Collaborator

Let me know when this is ready to go live and I'll take a look / push it to Crates.io.

@jeikabu
Copy link
Owner Author

jeikabu commented Dec 22, 2019

Let me know when this is ready to go live and I'll take a look / push it to Crates.io.

Should be pretty close. Go ahead and take a look.
This has gotten pretty messy, let me look at cleaning it up a bit.

@neachdainn
Copy link
Collaborator

neachdainn commented Dec 22, 2019

Looks good to me. I'll push it when you say it's ready.

EDIT: And after it is merged into master.

}
}
}

impl nng_pipe_ev {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This enum doesn't match the others with try_convert_from and TryFrom implementation. It's small enough to not really matter, though.

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I remember correctly, those were just a temporary solution before TryFrom was stabilized, and nng_pipe_ev didn't exist then. Once we no longer care about Rust <1.34 we can just remove try_convert_from. Doesn't make sense to make them deprecated since there isn't a replacement for earlier rust.

arg2: ::std::os::raw::c_int,
arg3: *mut ::std::os::raw::c_void,
),
unsafe extern "C" fn(arg1: nng_pipe, arg2: nng_pipe_ev, arg3: *mut ::core::ffi::c_void),
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a source of potential UB that the Rust wrappers can't guard against. C does not enforce that the nng_pipe_ev will be one of the allowed values and it is UB in Rust to not be a variant. It may be best to change the Bindgen settings to not use actual enums for the NNG enum types.

Copy link
Collaborator

@neachdainn neachdainn Dec 22, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To be clear, I think having C enums as argument is good (Rust will enforce valid variants) but anywhere an enum is received is immediately potentially UB. See the Rust language reference. Using repr(u*) instead of repr(C) does not alleviate the issue.

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, let's switch them.

@jeikabu
Copy link
Owner Author

jeikabu commented Jan 3, 2020

@neachdainn Merge?

@neachdainn
Copy link
Collaborator

I'm having issues building this. I'll figure out why and then report back.

@neachdainn
Copy link
Collaborator

neachdainn commented Jan 6, 2020

The issue seems to be with the nng-stats feature. Trying to build without that feature enabled leads to errors with undeclared types within the C code (stats_lock, stats_root). I'm not sure if this is a bug in the build script or if it's a bug with NNG's build.


Opened nanomsg/nng#1114 to address this. We could remove the feature and submit a new version but I would prefer to wait until this is fixed in NNG. That being said, I'm very eager to get a v1.2.* crate pushed and I'll be more open to removing the feature if NNG doesn't have a fixed release soon.

It appears to be fixed on the NNG master branch. So we can either remove the nng-stats feature or we can wait until v1.2.4

@jeikabu
Copy link
Owner Author

jeikabu commented Jan 6, 2020

Yes, apparently it's broken in 1.2.3.

There's no sense in removing nng-stats, would just have to put it back in. The normal thing to do would make it a "known issue" in 1.2.3. Let it be fixed in 1.2.4- who knows when that will be and what else might be broken.

@jeikabu jeikabu closed this Jan 6, 2020
@jeikabu jeikabu reopened this Jan 6, 2020
@neachdainn
Copy link
Collaborator

That sounds reasonable to me. You have my support to do the merge whenever you're ready.

@jeikabu jeikabu merged commit c3c5a0e into master Jan 7, 2020
@jeikabu jeikabu deleted the feature/nng_1.2 branch January 7, 2020 07:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants