I'd go about the problem in a different manner. Blindly doing pattern matches for interesting stuff (e.g. /int\s+(\w+);/) will get you into trouble, will require a lot special-case attention, and might well take longer with debugging and all than using a real grammatical parser. Even that snippet right there is wrong in at least three ways, despite looking casually right.

But parsing is a really big wheel to reinvent. I've done it, and it can be enlightening and entertaining, but if you just want functionality, go for a c(p)anned solution. Perl already has some parser modules, like Parse::yapp. All you need to use yapp (note: I haven't used it) is a yacc-compatible grammar, which you should be able to download for any C variant out there.

Of course, a parser won't solve your problem for you. Once you have a parse tree, you'll need to dig through it to find all the functions, variables, and other such goodness, but the elements will be much more accesible.

If you're willing to learn about lexers and parsers (which you really should!), this is the way to do it, especially since you've got multiple source files. I just have an itching feeling that once you start trying to do everything by hand you'll quickly run into a bunch of tall, spiky walls. But if you still want to do it the naive way, I don't really see a problem with modifying globals, though be aware that a variable declared with my isn't necessarily global: it's only accesible to subs declared after the variable. Go back and read the scoping docs. Passing a hashref like you say would only lengthen your parameter list by one item, and getting comfortable with dereferences wouldn't hurt. It's also a good practice, generally.