-
-
Notifications
You must be signed in to change notification settings - Fork 57
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
Nested named structs names are not detected. #117
Comments
FWIW I'm using the following command:
|
Another note, after digging through the logs, the interesting thing is that I can see the actual name of the struct being detected as a field FIELD_DECL, where the expected name in this edited log snippet is `
|
The following is a simple test showcasing the behavior I'm seeing as well an accompanying c file with the desired use of the struct I would need in my python code. |
@RobertHerreraEECS can you confirm this is fixed in the main branch ? |
Thanks for getting this ticket first off! This seems like a partial fix but definitely much better results. Unfortunately, it seems like the current patch and tests only account for the only 'fields' inheriting the For instance I would expect the following in test case
Let me know if this doesn't fit within the scope of functionality ^. If it doesn't, feel free to close the ticket. Thanks again. |
@RobertHerreraEECS I'm sorry I do not understand the test case you are proposing. |
Ah, I think I understand, you mean you would like
is that what you were asking ? |
Yes exactly! "A type declaration for an anonymous union, that is named field should carry the name of the field (union_s_1 -> union_s_u)". Let me know what you think. I think its quite portable for most use cases. From a C standpoint if I see a structure that is both named and typedef usually the code base resorts to only using the typdef alias. So my proposition would be if it the structure was unnamed ( |
Modified get_unique_name to also account for a the parent node's typedef name, if one exists. This change is a continuation to trolldbois#117 where the edge cases arise if more than one level of anonymous typedef'd structs are embedded inside each other. - Helper function created to determine if parent typdef name exists.
Currently clang2py (ctypeslib) has some small issues detecting named structs that have been nested in a union.
For my use case the following error can be replicated with the following similar structure:
`struct foo {
}`
The resultant struct that
clang2py
generates would look something along the lines of the following:`
`
The generated indicies above are merely an example of real outputted data I'm encoutering but the example does effectively illustrate the issue. In short, I would expect
0_8_0_0
to bebar
.I think either the issue might be that the resultant llvm thats generated by clang is interpreting the struct as an anonymous struct when in fact is a named struct. OR it could be a edge case in the struct decls parsing thats going on under the hood with ctypeslib.
The text was updated successfully, but these errors were encountered: