mumbel

same for master (6fad151b5440de3dfdd619df7b5dc070b2b4dc6c), fails to make a 128-bit scalar. I can't find the specific issue I'm thinking of, but I do recall 64-bit scalars being the limit and any...

just to clarify, the global is typed already at this point and there is a committed function signature, so just surprising that reading the symbol using my script above or...

I've been working in a larger binary, and the example above is just the stripped down setup. I can try to get a byte string/ELF together that shows this behavior...

I'll play around with getting a repro sample tonight. In my big binary, if I currently have both signature and global typed correctly, I see `setup_this_thing(foo_thing, toggle)` in the decompiler...

`00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 94 21 ff f8 7c 64 1b 78 3c 60 04 00 7c 08...

No I don't think I've named them anywhere in my larger image. its always just been `thing_t_ARRAY_ADDRADDR` And... yeah, naming it fixes it. edit: I guess that's why I've had...

Is your function definition committed for `actual_func`? You can tell by looking at the listing window and comparing to the decompiler, both should show the same return type and params....

Sorry, I don't know the answer to when/why params/return are committed or not, just that seems to be the cause when issues like this come up. I try to commit...

@emteere Do you foresee this being incorporated into structure merges (update/commit to archive and in VT) or just creation/editing? Hopefully somewhat the same logic and its just a matter of...

Why should the C parser be responsible for parsing invalid C that doesn't compile. Your prototype says return `unsigned long` and you don't return anything.