----- Original Message ----- From: "Andrew DeFaria"
Oh Inline::C worked fine. It's just when they compiled it with their gcc it would spit out an error or warning and they'd get dinged.
I suspect that if they hadn't been hit by compile-time errors then they would've been hit by the same runtime errors as I got.
They wanted me to rewrite their source files on the fly as a workaround. I asked them "How do I do that when the file is under Clearcase and not writable?". I told them "The right solution would be to get Inline::C (or actually Parse::RecDesent) fixed". I have since left that contract but I still pursue it somewhat in the interest of professionalism.
I always use the ParseRegExp.pm parser instead of Parse::RecDescent - it's much faster and hasn't yet let me down. (I should also point out that P::RD has also not let me down ... but, omg, it *can* be slow.)
Attached are 2 small patches - to lib/Inline/C/ParseRegExp.pm and C.pm. The latter is only to silence an 'uninitialized' warning that comes about as a consequence of the former. IINM, they allow one to specify the "(void)" argument, without disallowing us from specifying "()".
It will, of course, only work with scripts that have the config option: USING => 'ParseRegExp',Otherwise you're stuck (for the time being at least) with specifying "()" ... until someone fixes the P::RD parsing. I might take a look later on and see if this can be addressed from within Inline::C. If it can't, then I'll leave it to someone who thinks that P::RD is "fun". (Yes, looking at you David Mertens ;-)))
Also attached is a test script that's not yet very thorough.Please feel free to kick and punch these changes mercilessly - and let me know if they show some weakness.
In a week or so, if there's no problems reported, I'll upload them in a devel release so we can see what the cpan-testers make of them.
Cheers, Rob
C.pm.diff
Description: Binary data
ParseRegExp.pm.diff
Description: Binary data
void_arg.t
Description: Binary data
