Still having some issues with macros, as well as other things

[hadrielk]

Hi, I was hesitant to raise this issue because I was so happy the recent regression for C-macros was fixed, that I was mentally ignoring any other problems. :) But I figured you might want to fix more issues, so I'm submitting this one...

There are still cases of C-macro-based symbols not getting found: either not finding them at all, or it jumping to the appropriate header file but only to the top of it and not to the actual definition location.

This occurs frequently for me when using this ctags package on the source repo of Wireshark (http://www.wireshark.org). I'd love to help debug this problem if I can, but I'm not sure how to go about that. (I don't know Python and don't know how your package works, other than it using the ctags-generated tag file)

[hadrielk]

Of course I said the above and then went trying to debug it anyway. ;)

I think the problem for the case of only going to the top of the header file, is the regex being used is invalid. For example, the .tags file has this:

SET_ADDRESS epan/address.h  /^#define   SET_ADDRESS(/;" d

Because the definition of SET_ADDRESS happens to have an opening parenthesis after it. But that would make it an invalid regex, assuming you're doing that. (I'm guessing) If you're using these as regex patterns during symbol lookup, all regex "special" characters should be escaped I think. (i.e., *, +, [, ], (, ), ?, etc., should b escaped)

[stephenfin]

Yeah looks like an issue. Can you give me a brief version of that SET_ADDRESS macro. The opening parenthesis is likely the issue and I'd like to update my unit tests so I can fix it. Alteratively, if you want to have a look yourself, the regex is TAG_RE in ctags.py.

[hadrielk]

Sure, this particular one is:

#define SET_ADDRESS(addr, addr_type, addr_len, addr_data) \
    set_address((addr), (addr_type), (addr_len), (addr_data))

[hadrielk]

BTW, that's for the second issue, for the first issue of not finding them at all, it only appears to be an issue when it's a defined macro in the same .c file that it's being looked up from. For example, the epan/dissectors/packet-wsp.c file in Wireshark's source has the following:

#define PORT_NUMBER_INCLUDED    0x40

Then in some later code in that same file it has that macro name, but when trying to look it up I get Can't find "PORT_NUMBER_INCLUDED". The .tags file has this:

PORT_NUMBER_INCLUDED    epan/dissectors/packet-wsp.c    /^#define PORT_NUMBER_INCLUDED /;"  d   file:

[stephenfin]

Can you checkout HEAD on development - there's a patch there that may well fix one or both of these issues.

[aakshintala]

The issue of jumping to the top of the correct header but not to the line where the Macro is defined, still exists in 0.3.8. Was this fix checked in? Should I pull HEAD and confirm if this fixes the issue?