On Fri, Jul 13, 2012 at 12:47 PM, Eli Zaretskii <e...@gnu.org> wrote: >> Date: Fri, 13 Jul 2012 12:36:44 -0700 >> From: Doug Evans <d...@google.com> >> Cc: gcc-patches@gcc.gnu.org, gdb-patc...@sourceware.org >> >> On Fri, Jul 13, 2012 at 12:21 PM, DJ Delorie <d...@redhat.com> wrote: >> > >> > I think it's confusing to have filename_cmp and filename_eq that do >> > basically the same thing. Perhaps filename_eq should be >> > filename_cmp_v or filename_cmp_hash or something, to indicate that >> > it's *supposed* to be the same functionality as filename_cmp but with >> > a different signature? >> >> To be clear, filename_cmp is to strcmp as filename_eq is to streq. >> >> ref: STREQ in libiberty/regex.c: >> # define STREQ(s1, s2) ((strcmp (s1, s2) == 0)) >> >> Given that, I think the names are fine as is, but I'm happy to change them. > > Sorry if I'm missing something, but why do we need to advertise such a > function at all? Given that libiberty already provides filename_cmp, > isn't it trivial to write something like filename_eq whenever someone > needs to use hashes of file names?
It's a "matched set" with filename_hash. The hashtab.c constructors take a hash_f function pointer and an eq_f function pointer.
