Fix C printer output of array types in typedefs#12
Conversation
|
@ircmaxell why are non function typedefs handled differently here? php-c-parser/lib/Printer/C.php Lines 53 to 58 in d543087 |
|
Honestly, I don't remember. That code always gave me lots of problems conceptually for some reason (it's re-used in a few parts), and I am not sure why any of it is how it is. I am sure that I ran into a situation that this appeared to solve, but apparently not... |
* more test cases * force * to right side of space
|
@ircmaxell Maybe appending names to functions did not work... I dropped special handling & isFunction (might be a bc in case someone extended the C printer). I did a quick run against (a cleaned up) rdkafka.h (mhhh ... no arrays here) and uuid.h. Looks good. Running against llvm would be helpful. |
To my knowledge nobody is other than FFIMe, but can ship a major version bump if that's a big deal (I doubt it).
It's less about preference and more about the meaning of the construct. Doesn't the position change the meaning of the declaration? |
Right. I missed the space. I meant the right side of the space:
Parentheses and arrays seem also quirky:
Will take a look at this. |
|
Ah, as far as space, I don't really have a preference. So happy to accept whatever :) |
|
This example helped a lot with arrays and paranthesis:
See http://unixwiz.net/techtips/reading-cdecl.html. @ircmaxell could you please take if this PR works for you. |
|
This also fixes the "function type issue" mentioned in #2. |
|
Are you good with this as is? If so, I'm happy to merge. |
|
Stumbled over the minor void trailing space issue and fixed it. I successfully tested binding rdkafka, snappy, uuid, portalaudio and ffi with the c printer output. |
|
Awesome, Thanks!!! |
#11 - WIP
Added typedef array to test case.