bug#73484: 31.0.50; Abolishing etags-regen-file-extensions

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 10 Oct 2024 01:22:13 +0300
> Cc: pot@gnu.org, spwhitton@spwhitton.name, 73484@debbugs.gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 09/10/2024 22:11, Eli Zaretskii wrote:
> 
> >> This is basically a "uniqueness" operation using linear search, O(N^2).
> > 
> > Yes, this seems to be a protection against the same file name
> > mentioned more than once on the command line..
> 
> Or, maybe more likely, against having symlinks scanned if the symlink 
> target is also in the passed list.

Yes, that, but also any other possible ways of specifying the same
file twice, like having a file both compressed and uncompressed, etc.

> >> Is there a hash table we could use?
> > 
> > Something like that should do, yes.
> 
> Can we use search.h? hcreate/hsearch/etc. IIUC it's on in the C stndard, 
> and 
> https://www.gnu.org/savannah-checkouts/gnu/gnulib/manual/html_node/hcreate.html 
> says it's available on certain platforms.

I think we shouldn't: it is not sufficiently portable and Gnulib
doesn't have an implementation for it for those platforms that don't
have it.

We could perhaps use the standard tsearch (although it will be more
expensive).  Alternatively, we could steal the hash table code from
somewhere, for example, from Gawk.

> >> Or perhaps we would skip the search when the canonicalized name is the
> >> same as the original one.
> > 
> > That's not the same as the loop above does, I think.
> 
> If we assumed the duplicate check is only necessary for symlinks, and 
> there is on average a small number of them, I think we could avoid using 
> a hash table. But passing the same exact file 2 times would result in 
> duplicate tags.

canonicalize_filename in etags.c does not resolve symlinks, AFAICT, so
the symlink scenario will not be solved by that.  We'd need realpath
or its equivalent, I think?