如何从位于 /usr/include 的 Linux 头文件中获取函数名称
我们在 /usr/include 中拥有大部分 Gnu C 库头文件
我正在寻找一种方法来打开和读取包含文件并解析它以打印位于其中的所有声明的函数。
任何人都可以解释或提供一个讨论此标题格式的链接。
我这样做是因为我正在尝试做一个 C 自动完成插件，如果我包含 file.h，该插件将为我提供位于 file.h 中的所有函数。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
每个人在其职业生涯中最终都会至少需要一次这样的工具；它将扫描 C 源代码并打印出函数/变量名称列表或各个模块之间函数调用的交叉引用。
为了充分完成您所要求的任务，您必须编写基本上是 C 编译器前端的东西；再多的正则表达式魔法也无法满足您的需求。获取 C 语言语法的可
yacc版本，并使用lex和yacc（或flex和bison，或您选择的工具）。但是，当您匹配函数声明时，您只需将其打印出来（或将其保存到数据库或类似的东西），而不是生成机器指令。通过现有的 C 预处理器（例如
gcc -E）运行感兴趣的标头，以去除注释并执行任何宏扩展，然后将生成的文件输入到解析器中。编辑
现在我实际上去阅读了
gcc手册页，有一个选项-aux-info可以编写所有函数的原型声明在翻译单元内声明/定义，包括在包含的头文件中声明的。更好的是，输出的格式很好并且很规则，并且应该相当容易解析。所以，我们吸取了教训：检查你的编译器文档，并忽略像我这样仍然用 80 年代老式工具思考的老家伙。
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 usinglexandyacc(orflexandbison, 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
gccman page, there's an option-aux-infothat 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.
Doxygen 可以做到这一点。通常它在 C 源代码上运行，该源代码已对其优点进行了注释，但它也可以在没有任何标记的情况下从代码生成文档，并且您可以使用您选择的工具解析其 XML 输出（或其他格式）。获取现成的 XML 解析器并将其集成到您的应用程序中比编写 C 解析器更容易。
顺便说一句，对于您的 C 自动完成插件来说，建议恰好在您的实现的头文件中但未由 (a) C 标准、(b ) POSIX 标准，(c) GNU 扩展文档。就我个人而言，我会将标准标头视为自动完成的特殊情况。它们具有定义良好的接口，列出了您应该期望的所有功能，但它们也可能包含私有实现垃圾。
不过，该私人垃圾将具有保留名称，因此您可以继续但排除保留名称。
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.
Glibc 的标头非常复杂，有很多间接性，所以我猜它们对于您想要做的事情来说是最坏的情况。
也就是说，cscope 为我使用 string.h 进行简单测试提供了合理的输出：
第一个 cscope 调用用于生成 cscope 数据库，第二个调用是命令行cscope 搜索全局标识符（是的，1 不直观）。
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,
cscopegives me reasonable output for a simple test usingstring.h: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).
如果您想要特定的标准库模块，请通过 Google 搜索。例如：
http://www.cplusplus.com/reference/clibrary/cstring/
这是谷歌搜索“string.h”的第一个结果。它包含 cstring 中提供的所有函数的详细信息。
如果您想跟踪 /usr/include 的所有子目录中的所有标头中的所有函数，我可以给您一个简短的 bash 脚本来执行此操作，但我真的不明白这一点。
干杯!
编辑：或者正如扎克上面评论的那样，有标准库手册 。很好的链接，扎克！
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!
手册页的
0p部分包含 POSIX 标头的手册页，以及每个标头中定义的内容（或者更确切地说应该）。Section
0pof the man pages contains man pages for POSIX headers, along with what is (or rather should be) defined in each.编写一个 LEXer 和一个 YACCer 来检查开发人员的源代码并将其与开发人员的 $INCLUDE_PATH 中的源代码进行匹配。
包含路径中的文件与普通头文件具有相同的格式。关键词相同；但是您可能会遇到像“extern”这样的词，这对于初学者程序员来说可能并不常见。我建议您对关键字有完整的了解，并了解它们在头文件中不同位置的功能。
ps：对于更复杂的解决方案，您将不得不考虑条件宏。
干杯。
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.
使用实际的编译器来解析怎么样？我认为这是一个非常有前途的发展：
http://codesynthesis.com/~boris/blog/2010/05/03/parsing-cxx-with-gcc-plugin-part-1/
哦，另一种可能性是看看在目标文件中的调试信息。
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.