Add support for converting from winapi types #336
No reviewers
Labels
No labels
breaking
bug
dependencies
good first issue
help wanted
unstable
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
gh-uuid-rs/uuid!336
Loading…
Reference in a new issue
No description provided.
Delete branch "feature/winapi"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
I'm submitting a(n) feature
Description
Add a module
guid_supportthat contains methods on Uuid for converting to and from winapi::shared::guiddef::GUID. Along with this an optional dependency on winapi is added.Motivation
#333
Tests
Not yet, waiting for a VM (will update once I have run tests)
Related Issue(s)
closes #333
winapi_support@ -26,6 +26,10 @@ all-features = true[package.metadata.playground]0.3use winapi::shared::guiddefguid: guiddef::GUIDguiddef::GUID@ -0,0 +1,65 @@use prelude::*;Document assumption that the
Uuidis LE@Redrield thanks for working on this.
Get the assumption documented and it will be ready for merge
@ -0,0 +1,65 @@use prelude::*;I could have it use whichever endianness the
Uuidis.Uuid::to_fields_leis the only method I found, and is actually the outlier, with the other methods being prefixedas_Doc comments are changed, I'm still waiting for this VM so that I can add tests and such to verify functionality. Once that's done I'll remove [WIP] so that it can be merged
Another thing that I could do, now I think of it is make
Uuid::to_guid_leandUuid::to_guid_beif wanted👍 We'll need some roundtrip tests to make sure
Uuids converted intoGuids result in the same values, and thatUuidassigns the fields of theGuidin the same way as Windows APIs do.Hmm, I don't think this would make a lot of sense here, would it? Since the fields of the
Guidare primitive integers, they'll just use the platform endianness.Got this code for a test
and it's failing, looks like from an endian mismatch. from_guid uses from_fields, so is that endian dependant?
@Redrield I'm thinking the
from_fields_lecall is the problem here and we probably want to usefrom_fieldsinstead.There is no
from_fields_lefrom what I can see. There'sfrom_bytes_lebut that takes a single unified array, not the individual fieldsSorry, I meant
to_fieldsrather thanto_fields_le:)That was indeed the problem. Are there any other tests that are going to be wanted other than that one? I'll add them before I push the final code for merge
@Redrield one from guid to uuid will be helpful
bors: r+
Build succeeded