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

Better cgo support #11

Closed
AlekSi opened this issue Mar 23, 2013 · 4 comments
Closed

Better cgo support #11

AlekSi opened this issue Mar 23, 2013 · 4 comments

Comments

@AlekSi
Copy link

AlekSi commented Mar 23, 2013

This can be made smaller:

 buf: ([1024]foo._Ctype_char) {
  (foo._Ctype_char) 115,
  (foo._Ctype_char) 100,
  (foo._Ctype_char) 102,
  (foo._Ctype_char) 115,
  (foo._Ctype_char) 100,
  (foo._Ctype_char) 102,
  (foo._Ctype_char) 115,
  (foo._Ctype_char) 100,
  (foo._Ctype_char) 102,
  (foo._Ctype_char) 115,
  (foo._Ctype_char) 0,
  (foo._Ctype_char) 0,
  (foo._Ctype_char) 0,
  ...
@davecgh
Copy link
Owner

davecgh commented Mar 25, 2013

This is a reasonable request. I haven't spent much time dealing with cgo types under reflection, so I'm not sure how much is possible, but I'll take a look.

@davecgh
Copy link
Owner

davecgh commented Mar 29, 2013

After looking into this a bit tonight, I see that C.char is considered signed as an int8 under reflection. As a result, the hexdump style functionality is bypassed since it only works with uint8.

There are a couple of ways to handle this. One way is to allow spew to hexdump int8 slices as well as uint8 slices, but I don't think that's really desirable for most cases. Another option that is a bit hackish is to look at the textual type (versus the reflected type) specifically to detect something like the pattern ^.*\._Ctype_char$ and hexdump it from there after a bit of casting.

Any thoughts?

@AlekSi
Copy link
Author

AlekSi commented Mar 29, 2013

I think looking for ^.*\._Ctype_char$ is okay if user is opted in for it.

davecgh added a commit that referenced this issue Sep 22, 2013
This commit adds support for dumping a few cgo types like hexdump -C as
requested in issue #11.  In particular, it now handles char [#], unsigned
char [#], and uint8_t [#].
@davecgh
Copy link
Owner

davecgh commented Sep 22, 2013

This feature, including new tests and an updated test coverage report has been implemented as of commit 1fe9f5c.

@davecgh davecgh closed this as completed Sep 22, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants