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

Add support for discriminated unions and optional data #6

Open
wants to merge 8 commits into
base: master
Choose a base branch
from

Conversation

rasky
Copy link

@rasky rasky commented Sep 13, 2015

This PR adds support for:

  • Discriminated unions (RFC 4506, 4.15)
  • Optional data (RFC 4506, 4.19)

In both cases, the code relies on struct tags to convey the required metadata information. Please see the individual commits for more information.

@davecgh
Copy link
Owner

davecgh commented Sep 16, 2015

Thanks for the PR. I'll review it this weekend.

@rasky
Copy link
Author

rasky commented Sep 22, 2015

ping :)

@rasky
Copy link
Author

rasky commented Oct 24, 2015

Hi, any chance to get this reviewed? I need to release libraries based on this, and I would like to avoid a permanent fork if possible at all.

@jhbe
Copy link

jhbe commented Nov 28, 2015

Ping. :)

This is just what I need, but like rasky I'd rather use the main repo if possible.

@rasky
Copy link
Author

rasky commented Aug 14, 2016

Ping again on this :) I've been using my fork with success in production, I think the modifications in this PR are correct. If you're concerned with styling, let me know.

@marcopeereboom
Copy link
Contributor

Can you redo this PR and I'll push for it to go in.

@prashanthpai
Copy link

Thanks @rasky for working on this. I'd love to see this PR land in the main repo. What is it that needs to be done here to get this in ?

Thanks.

rasky added 6 commits January 24, 2017 17:29
The usage of absolute import paths in testsuite is not compatible
with allowing a package to easily fork. One has to replace all
global paths in test files. I tried to use relative import paths
such as "../xdr2" but there appears to be a Go 1.5 bug for which
the internal_test.go functions TstEncode/TstDecode are not exposed
to tests.
Unions are represented by normal Go structs, using
different struct tags to pinpoint the union discriminant,
and to select the various cases.

Since more struct tags were required, I introduced a new
general tag called "xdr" with key/value options, and thus
changed the previous "xdropaque" struct tag into the new
canonical name form `xdr:"opaque=false"`, while retaining
the previous form for backward compatibility.
In Go, they are expressed through indirection: a pointer
to the actualy data, that can be nil to express that the
field is missing. The field must be marked with the new
tag option "optional", because otherwise it is automatically
indirected as per default behaviour of marshallers.
@rasky
Copy link
Author

rasky commented Jan 24, 2017

Hi, I've rebased the PR and also completed coverage (100%).

I would appreciate if you could merge this PR @marcopeereboom @davecgh

Copy link
Contributor

@marcopeereboom marcopeereboom left a comment

Choose a reason for hiding this comment

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

I am mostly ok with this diff. Some minor nits.

@davecgh can you have a peek too?

@@ -14,14 +14,12 @@
* OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
*/

package xdr_test
package xdr
Copy link
Contributor

Choose a reason for hiding this comment

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

I am sure @davecgh has a reason to split test from package. Seems like a gratuitous change.

Copy link
Author

Choose a reason for hiding this comment

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

The point is that this style of testing makes forking impossible, because of the absolute import path used to import the xdr2 package. And unfortunately, you can't use relative imports in this context.

So for instance, the CI would be unable to test this pull request because it would use the upstream version of the xdr2 package, rather than the version in this branch.

xdr2/tag_test.go Outdated
@@ -0,0 +1,45 @@
/*
* Copyright (c) 2012-2014 Dave Collins <[email protected]>
Copy link
Contributor

Choose a reason for hiding this comment

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

Pretty sure @davecgh didn't write this :-) Date is wrong to boot.

xdr2/tag.go Outdated
@@ -0,0 +1,73 @@
/*
* Copyright (c) 2012-2014 Dave Collins <[email protected]>
Copy link
Contributor

Choose a reason for hiding this comment

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

Wrong author and date.

xdr2/tag_test.go Outdated
@@ -0,0 +1,45 @@
/*
* Copyright (c) 2012-2014 Dave Collins <[email protected]>
Copy link
Contributor

Choose a reason for hiding this comment

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

Wrong author and date.

@rasky
Copy link
Author

rasky commented Feb 17, 2017

I've updated the copyrights.

@dougm
Copy link

dougm commented Feb 21, 2017

👍 ran into the need for this recently, would be great to have it merged. cc @fdawg4l

@marcopeereboom
Copy link
Contributor

I spoke to @davecgh about this and we want it if it becomes xdr3. xdr2 API is set in stone and we don't want to modify it.

@rasky
Copy link
Author

rasky commented Feb 21, 2017

Can you please clarify how the API is modified? AFAICT it's retro compatible in pure go 1 sense

@vtolstov
Copy link

vtolstov commented Apr 21, 2017

any news? I need xdr3 package and i need to distinglish between string and string pointer.
Because I'm decode libvirt rpc data and:

 There are basically two types of strings when it comes to XDR. 
The first one is nonnull_string, which are encoded [length][string]. 
With just this it would be impossible to differentiate between NULL 
and an empty string "" as both would be encoded in the same way. 
Therefore, there is remote_string (libvirt terminology) or 
xdr_pointer (XDR terminology) which encodes a pointer as [bool][pointer] where 
bool is either 00 00 00 00 meaning the pointer is NULL or something else (e.g. 00 00 00 01) meaning the pointer has a non-NULL value.

@marcopeereboom
Copy link
Contributor

I will look at this soon. Remind me again if I forget.

@vtolstov
Copy link

@marcopeereboom ping...

@vtolstov
Copy link

@davecgh can you merge this on create xdr3 ? I'm really need this pr and it sit in this repo 2 years...

@rasky
Copy link
Author

rasky commented Oct 25, 2017

I still don’t see why xdr3 is needed for a perfectly backward compatible PR.

@vtolstov
Copy link

ok @davecgh please merge it, or if you don't interests in this package add unmaintained info to readme .
And all who need new features can use rasky repo

andersk added a commit to andersk/go-nfs-client that referenced this pull request Jan 19, 2018
Commit 7592fd7 makes use of the
`xdr:"union"` and `xdr:"unioncase=N"` annotations that were submitted
in a pull request that has not been merged upstream to davecgh/go-xdr:

davecgh/go-xdr#6

Without support for these annotations, the code crashes at runtime.

Signed-off-by: Anders Kaseorg <[email protected]>
andersk added a commit to andersk/go-nfs-client that referenced this pull request Jan 19, 2018
Commit 7592fd7 makes use of the
`xdr:"union"` and `xdr:"unioncase=N"` annotations that were submitted
in a pull request that has not been merged upstream to davecgh/go-xdr:

davecgh/go-xdr#6

Without support for these annotations, the code is unable to parse a
valid FSINFO reply.

Signed-off-by: Anders Kaseorg <[email protected]>
matthewavery pushed a commit to vmware-archive/go-nfs-client that referenced this pull request Feb 1, 2018
Commit 7592fd7 makes use of the
`xdr:"union"` and `xdr:"unioncase=N"` annotations that were submitted
in a pull request that has not been merged upstream to davecgh/go-xdr:

davecgh/go-xdr#6

Without support for these annotations, the code is unable to parse a
valid FSINFO reply.

Signed-off-by: Anders Kaseorg <[email protected]>
@andrewrk
Copy link

bumpity humpidy dump

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.

8 participants