How to get functions names from Linux headers located in /usr/include

Question

We have most of Gnu C Library Headers in /usr/include
I'm looking for a way to open and read an include file and parse it to print all the declared functions which are located inside it.
and can any one explain or provide a link talking about this headers formatting.
I doing this because I'm trying to do an C Auto completion plug-in which if I include a file.h the plug-in will give me all functions are located in the file.h.

Answer 1

If you want specific standard library modules, Google them up. For example:

http://www.cplusplus.com/reference/clibrary/cstring/

That was the first result of Googling "string.h". It has details on all functions provided in cstring.

If you want to track down all functions in all headers in all subdirectories of /usr/include, I can give you a short bash script to do so, but I don't really see the point.

Cheers!

Edit: or as Zack commented above, there's the standard library manual. Good link, Zack!

Answer 2

Section 0p of the man pages contains man pages for POSIX headers, along with what is (or rather should be) defined in each.

Answer 3

Everyone eventually asks for a tool like this at least once in their careers; something that will scan C source code and print out a listing of function/variable names or a cross-reference of function calls between various modules.

To adequately do what you're asking, you're going to have to write what is basically a C compiler front end; no amount of regular expression magic is going to give you what you want. Grab a yaccable version of the C language grammar and womp up a parser using lex and yacc (or flex and bison, or your tools of choice). However, when you match a function declaration, instead of generating machine instructions you'll just print it out (or save it to a database, or something like that).

Run the header of interest through the existing C preprocessor (e.g. gcc -E) to strip out comments and do any macro expansion, then feed the resulting file into your parser.

EDIT

And now that I actually go read the gcc man page, there's an option -aux-info that will write the prototype declarations of all functions declared/defined within the translation unit, including the ones declared in the included header files. Even better, the output is somewhat nicely formatted and regular and should be reasonably easy to parse.

So, lesson learned: check your compiler documentation and ignore old farts like me who still think in terms of '80s-vintage tools.

Answer 4

Write a LEXer and a YACCer that checks the developer's source and matches them with the source code from the developer's $INCLUDE_PATH.

The files in the include path have the same format as normal header files. The keywords are the same; but you may run into words like 'extern' which may not be mundane to a beginner programmer. I suggest you have a complete knowledge of the keywords and understand their functionality at different points in the header files.

p.s: For a more complex solution, you will have to consider the conditional macros.

Cheers.

Answer 5

Doxygen can do this. Usually it's run on C source which has been annotated for its benefit, but it can also produce documentation from code without any markup, and you can parse its XML output (or other formats) with the tools of your choice. Grabbing an XML parser off the shelf and integrating it into your app is easier than writing a C parser.

By the way, it might not be wise for your C auto-completion plugin to suggest things which just so happen to be in the header file in your implementation, but which are not specified by any of (a) the C standard, (b) the POSIX standard, (c) GNU extension documentation. Personally I would treat standard headers as a special case for auto-completion. They have well defined interfaces which list all the functions you should expect to be there, but they may also contain private implementation junk.

That private junk will have reserved names, though, so you could go ahead but exclude reserved names.

Answer 6

How about using the actual compiler to parse? I think this is a very promising development:

http://codesynthesis.com/~boris/blog/2010/05/03/parsing-cxx-with-gcc-plugin-part-1/

Oh, and another possibility would be to look at debug info in object files.

Answer 7

Glibc's headers are notoriously complex, having lots of indirection, so I'd guess they are about worst case for anything like what you're trying to do.

That said, cscope gives me reasonable output for a simple test using string.h:

$ cscope -bcq /usr/include/string.h
$ cscope -d -L1strcat
/usr/include/string.h strcat 92 extern char *strcat (char *__restrict __dest, __const char *__restrict __src)
/usr/include/bits/string.h strcat 963 #define strcat(dest, src) \
/usr/include/bits/string3.h strcat 164 #define strcat(dest, src) \

The first cscope invocation is for generating the cscope database, the second one is a command-line cscope search for global identifiers (yes, that 1 is unintuitive).