public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug preprocessor/100435] New: oddity in hash table use in libcpp
@ 2021-05-05 14:46 tromey at gcc dot gnu.org
  2021-05-06  6:27 ` [Bug preprocessor/100435] " rguenth at gcc dot gnu.org
  2021-05-07  0:06 ` tromey at gcc dot gnu.org
  0 siblings, 2 replies; 3+ messages in thread
From: tromey at gcc dot gnu.org @ 2021-05-05 14:46 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100435

            Bug ID: 100435
           Summary: oddity in hash table use in libcpp
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: preprocessor
          Assignee: unassigned at gcc dot gnu.org
          Reporter: tromey at gcc dot gnu.org
  Target Milestone: ---

I noticed that the libcpp hash tables in libcpp/files.c use
htab_hash_string, but compare filenames with filename_cmp.

This by itself is not a bug, in the sense that it can't cause
hash table corruption.

However, it seems strange, because it means that two filenames
that compare equal can hash differently, and so the hash tables
will not notice that they are "the same".

I think any problem here would most likely be a performance issue,
and only be available when either HAVE_CASE_INSENSITIVE_FILE_SYSTEM
or HAVE_DOS_BASED_FILE_SYSTEM is defined.

If this is in fact a bug, the fix would be to use filename_hash
rather than htab_hash_string in this file.  There are multiple uses
to fix.

If this is intentional, feel free to just close this bug.
I found this by reading the code while looking into something else,
and I thought it was odd enough to report; but I haven't encountered
any actual problem.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [Bug preprocessor/100435] oddity in hash table use in libcpp
  2021-05-05 14:46 [Bug preprocessor/100435] New: oddity in hash table use in libcpp tromey at gcc dot gnu.org
@ 2021-05-06  6:27 ` rguenth at gcc dot gnu.org
  2021-05-07  0:06 ` tromey at gcc dot gnu.org
  1 sibling, 0 replies; 3+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-05-06  6:27 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100435

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
I think it's just an omission and indeed a bug.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [Bug preprocessor/100435] oddity in hash table use in libcpp
  2021-05-05 14:46 [Bug preprocessor/100435] New: oddity in hash table use in libcpp tromey at gcc dot gnu.org
  2021-05-06  6:27 ` [Bug preprocessor/100435] " rguenth at gcc dot gnu.org
@ 2021-05-07  0:06 ` tromey at gcc dot gnu.org
  1 sibling, 0 replies; 3+ messages in thread
From: tromey at gcc dot gnu.org @ 2021-05-07  0:06 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100435

--- Comment #2 from Tom Tromey <tromey at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #1)
> I think it's just an omission and indeed a bug.

I can write a patch easily enough, but I don't have a good way to test it.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2021-05-07  0:06 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-05-05 14:46 [Bug preprocessor/100435] New: oddity in hash table use in libcpp tromey at gcc dot gnu.org
2021-05-06  6:27 ` [Bug preprocessor/100435] " rguenth at gcc dot gnu.org
2021-05-07  0:06 ` tromey at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).