You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am aware that I can switch the field definition to long, but these types are being pulled out of CastXML, and I'd prefer to fix the bug in Fiddle instead of implementing a bunch of type remapping.
old
parse_struct_signature() is passing the complete struct member definition to parse_ctype(). This includes both the ctype and the member name. This causes a problem when handling structs that contain compound members such as: int long length in their definition.
changed the title [-]parse_struct_signature() with "long int" member fails in parse_ctype()[/-][+]parse_ctype() fails for "int long len"[/+]on Dec 19, 2021
Oof, ok the fix for this is non-trivial. The ordering that comes out of CastXML (from the clang AST), is different for most of these types. It would require reworking parse_ctype() to handle unsigned and long at any point along the type string.
As an example of why this is difficult, each of these types are equivalent and valid, but only one of them is covered in parse_ctype():
unsigned long int (correctly handled by parse_ctype())
unsigned int long
long unsigned int
long int unsigned (yea, this one is weird, but I compiled it in gcc)
int unsigned long (weirder)
int long unsigned (weirdest)
For reference, here is the list of types that CastXML is using for one of my source files:
Activity
[-]parse_struct_signature() with "long int" member fails in parse_ctype()[/-][+]parse_ctype() fails for "int long len"[/+]dmlary commentedon Dec 19, 2021
Oof, ok the fix for this is non-trivial. The ordering that comes out of CastXML (from the clang AST), is different for most of these types. It would require reworking
parse_ctype()to handleunsignedandlongat any point along the type string.As an example of why this is difficult, each of these types are equivalent and valid, but only one of them is covered in
parse_ctype():unsigned long int(correctly handled byparse_ctype())unsigned int longlong unsigned intlong int unsigned(yea, this one is weird, but I compiled it in gcc)int unsigned long(weirder)int long unsigned(weirdest)For reference, here is the list of types that CastXML is using for one of my source files:
Instead of trying to fix this in fiddle, I'm just going to map the CastXML types into
u?int\d+_t.[ruby/fiddle] Add support for "long" variants
Add support for "long" variants