Page MenuHomeFreeBSD

ctags(1): Add recursive support.
Needs ReviewPublic

Authored by fernape on Feb 5 2021, 11:26 AM.
Tags
None
Referenced Files
Unknown Object (File)
Jan 1 2024, 2:26 AM
Unknown Object (File)
Sep 20 2023, 11:57 PM
Unknown Object (File)
Sep 11 2023, 1:50 AM
Unknown Object (File)
Aug 27 2023, 10:20 AM
Unknown Object (File)
Aug 25 2023, 3:07 AM
Unknown Object (File)
Jul 7 2023, 4:40 AM
Unknown Object (File)
Jul 4 2023, 5:09 PM
Unknown Object (File)
Jun 19 2023, 4:24 AM

Details

Summary

Use ftw(3) to support recursing subdirectories.

Do not treat duplicates as errors since this would limit the recursive feature
too much. Instead, keep the warning but add the duplicates to the output file.

This change does not violate POSIX since the output produced by duplicates is
implementation defined[1]

Most modern editors (Vim, Emacs, etc) handle multiple tags without problems.

vi(1) in base handles the tags file by assuming tag names are unique. vi(1)
still handles the new tags file correctly since it only jumps to the first
occurrence of the tag. Since we keep the old behavior this does not violate
POLA.

Note that find_entries now accepts a const char * so we can pass the ftw(3)
filled argument path respecting correctness. find_entries is not supposed to
change file anyway.

[1] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/ctags.html

Test Plan
  • Generate tags file in FreeBSD source repository with different combinations:

ctags -R ctags.c ctags.h ../, ctags usr.bin/ usr.sbin/, etc

  • Execute vi/vim -t tag with different tags (duplicated or not) and check the result

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 41848
Build 38736: arc lint + arc unit

Event Timeline

gbe added reviewers: imp, emaste.
gbe added a subscriber: gbe.

No objections from manpages.

This revision is now accepted and ready to land.Mar 3 2021, 7:47 PM
0mp requested changes to this revision.Apr 18 2021, 1:44 PM
0mp added a subscriber: 0mp.
0mp added inline comments.
usr.bin/ctags/ctags.1
41

Synopsis should be updated as well.

usr.bin/ctags/ctags.c
266

The usage message should be updated as well.

This revision now requires changes to proceed.Apr 18 2021, 1:44 PM
  • catgs(1): Update usage and SYNOPSIS

Now we need a src committer to review it.

This revision is now accepted and ready to land.Apr 19 2021, 8:13 AM
In D28488#669325, @0mp wrote:

Now we need a src committer to review it.

Thank you both for the review.

Let's wait...

In D28488#669325, @0mp wrote:

Now we need a src committer to review it.

Thank you both for the review.

Let's see if an src commiter can have a look.

pstef added inline comments.
usr.bin/ctags/ctags.c
97

style: fopen() doesn't return a boolean value; should be compared to NULL.

113

When is this freed?

  • Fix fopen() check as per pstef@ suggestion
  • Add comment clarifying obscure string freeing.
This revision now requires review to proceed.Sep 29 2021, 5:18 PM
fernape added inline comments.
usr.bin/ctags/ctags.c
97

Thanks!

113

That would be freed in the change in tree.c:130 (sorry, I don't know how to get a link to that change).
In pfnote() the file that is being processing is stored in np->file. Then, when the tree is freed, so it is the copied string.

I added a comment to clarify this. I don't know of a better place to release the memory.

I run`valgrind ./ctags -R ../ and it does not complain about //definitely lost// memory that I think it would be the case if we were overwriting curfile` all the time.