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

ffi: Expose CiphertextMessageType constants #17

Merged
merged 2 commits into from
Oct 23, 2020

Conversation

jrose-signal
Copy link
Contributor

Regular Rust code doesn't need CiphertextMessageType because it can already match on CiphertextMessage. On the other hand, FFI code could really use named constants for the various message types.

Copy link
Contributor

@jack-signal jack-signal left a comment

Choose a reason for hiding this comment

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

These are wire level constants so I think the enum values should still be in the main rust code. If you look at the Rust tests, they bake in assumptions on what message types are being provided which isn't possible in a real client. [One goal of Ehren's is that it should eventually be possible to write a complete albeit primitive Signal client entirely in Rust - that isn't possible if these values aren't available to properly decode incoming messages]

Certainly good to expose the enum values into Swift

@jrose-signal
Copy link
Contributor Author

Oh, I didn't realize those type values were part of the wire protocol, rather than some other disambiguator. I'll put it back, then.

Also:
- Expose them to Swift as well in a type-safe way
- Verify that each constant matches the encoding used in rust/protocol/
We were only using it on enums, and unconditionally at that, so Rust's
built-in numeric casts will have the same effect.
@jrose-signal jrose-signal changed the title Sink CiphertextMessageType down to be FFI-only ffi: Expose CiphertextMessageType constants Oct 22, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants