Anonymus nested structs
See original GitHub issueHi,
I’m trying to wrap the following struct:
struct ibv_odp_caps {
uint64_t general_caps;
struct {
uint32_t rc_odp_caps;
uint32_t uc_odp_caps;
uint32_t ud_odp_caps;
} per_transport_caps;
};
as follows:
cdef struct per_transport_caps:
unsigned int rc_odp_caps
unsigned int uc_odp_caps
unsigned int ud_odp_caps
cdef struct ibv_odp_caps:
unsigned long general_caps
per_transport_caps per_transport_caps
but get the following error:
warning: 'struct per_transport_caps' declared inside parameter list [enabled by default]
static PyObject* __pyx_convert__to_py_struct__per_transport_caps(struct per_transport_caps s);
warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default]
warning: 'struct per_transport_caps' declared inside parameter list [enabled by default]
static PyObject* __pyx_convert__to_py_struct__per_transport_caps(struct per_transport_caps s) {
error: parameter 1 ('s') has incomplete type
static PyObject* __pyx_convert__to_py_struct__per_transport_caps(struct per_transport_caps s) {
error: type of formal parameter 1 is incomplete
member = __pyx_convert__to_py_struct__per_transport_caps(s.per_transport_caps); if (unlikely(!member)) goto bad;
The Oreily book suggested to flatten the inner struct, but this also fails:
cdef struct ibv_odp_caps:
unsigned long general_caps
unsigned int rc_odp_caps
unsigned int uc_odp_caps
unsigned int ud_odp_caps
gets:
error: 'struct ibv_odp_caps' has no member named 'rc_odp_caps'
member = __Pyx_PyInt_From_unsigned_int(s.rc_odp_caps); if (unlikely(!member)) goto bad;
error: 'struct ibv_odp_caps' has no member named 'uc_odp_caps'
member = __Pyx_PyInt_From_unsigned_int(s.uc_odp_caps); if (unlikely(!member)) goto bad;
error: 'struct ibv_odp_caps' has no member named 'ud_odp_caps'
member = __Pyx_PyInt_From_unsigned_int(s.ud_odp_caps); if (unlikely(!member)) goto bad;
How do I wrap this properly?
Issue Analytics
- State:
- Created 6 years ago
- Comments:12 (2 by maintainers)
Top Results From Across the Web
C: How to access different types of anonymous or unnamed ...
C: How to access different types of anonymous or unnamed nested structs - Stack Overflow. Stack Overflow for Teams – Start collaborating and ......
Read more >Anonymous nested struct - Internals & Design - Julia Discourse
By “Anonymous nested struct” I mean defining a struct that has another struct with no name inside: struct ABC name::String data::struct ...
Read more >Anonymous struct and fields in Golang - Codekru
Struct fields with no name and just the data type are anonymous fields. We can use an anonymous field to access the inner...
Read more >Anonymous Union and Structure in C - GeeksforGeeks
Anonymous unions/structures are also known as unnamed unions/structures as they don't have names. Since there is no names, direct objects(or ...
Read more >Nested structs in Golang - Medium
The anonymous structure with two fields is only used to carry the foo and bar values during the function call, that's all.
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
hi, @noaos we were able to add the struct of per_transport_caps by using the following:
cdef struct per_transport_caps: uint32_t rc_odp_caps uint32_t uc_odp_caps uint32_t ud_odp_caps
what was missing is the import of : from libc.stdint cimport uint32_t
and this most likely why you had the error of : pyverbs/device.c:1827:56: error: unknown type name ‘ibv_odp_caps_sub’ static PyObject* __pyx_convert__to_py_ibv_odp_caps_sub(ibv_odp_caps_sub s);
the way to use it is by calling it like so: self.odp_caps.per_transport_caps.rc_odp_caps
I tried it and it worked for me
I’ve replicated your error now, but I also have some code in production that looks exactly the same, except it works.
I will try to understand what the difference is in a few days, after the holidays are over. Happy New Year!