Article View: gnu.gcc.help
Article #50253Re: super "tags" with gcc support
From: Ronald F. Guilmette
Date: Fri, 05 Nov 1993 10:19
Date: Fri, 05 Nov 1993 10:19
43 lines
2787 bytes
2787 bytes
In article <9310252122.AA26094@zeppelin.convex.com> helgaas@zeppelin.convex.com (Bjorn Helgaas) writes:
>> Besides using the undocumented "-aux-info" option of gcc, another
>> approach to building such a tool might be to start with yacc (or the GNU
>> equivalent) and an appropriate grammer for ANSI C (I've seen a few in the
>> public domain on various bulletin boards). Then, you'd just have to
>> build action procedures for the appropriate nonterminal definitions to
>> capture the data you're looking for (function names, data types,
>> parameters, where-used stuff, etc.).
>
>This would certainly be a plausible approach. It is exactly what our
>current tool, cscope, does. The problem is that this makes yet another
>tool that has to parse the C language. Even though grammars are available,
>it is difficult to do it exactly right, especially when you want it to
>always match the compiler.
Quite so. This is exactly the issue that Stallman (and others) miss when
they suggest creating totally separate front-ends to do source code
information-extraction jobs like this.
It's an important issue... especially with compilers which evolve as fast
as the GNU ones do. That's why I built protoize the way I did (to use
the existing compiler to do the information collection) even over
Stallman's protestations that this was not the "right way" to build
such a tool. (I note however that neither he not I have ever once
had to take the trouble to deal with a bug report stating that the
compiler and protoize have gotten out-of-sync with respect to the
languages they accept.)
>For example, cscope doesn't handle function
>definitions like this:
>
> void f(void (*pf)()) {...}
>
>correctly. The compiler already does all the parsing, and is more likely
>than anything else to do is correctly.
Exactly so.
--
-- Ronald F. Guilmette, Sunnyvale, California -------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------
Technical Details
Message-ID:
<rfgCG0Kot.I5u@netcom.com>Path:
arc1-ca.pugleaf.net!gmd.de!xlink.net!sol.ctr.columbia.edu!news.kei.com!eff!news.umbc.edu!europa.eng.gtefsd.com!library.ucla.edu!csulb.edu!csus.edu!netcom.com!rfgReferences:
<9310252122.AA26094@zeppelin.convex.com>Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 11318c,f2e83fb0e06c9303,start X-Google-Attributes: gid11318c,public X-Google-ArrivalTime: 1993-11-05 02:46:44 PST Newsgroups: gnu.gcc.help Path: arc1-ca.pugleaf.net!gmd.de!xlink.net!sol.ctr.columbia.edu!news.kei.com!eff!news.umbc.edu!europa.eng.gtefsd.com!library.ucla.edu!csulb.edu!csus.edu!netcom.com!rfg From: rfg@netcom.com (Ronald F. Guilmette) Subject: Re: super "tags" with gcc support Message-ID: <rfgCG0Kot.I5u@netcom.com> Organization: Netcom Online Communications Services (408-241-9760 login: guest) References: <9310252122.AA26094@zeppelin.convex.com> Distribution: gnu Date: Fri, 5 Nov 1993 10:19:40 GMT Lines: 43