[Bug libc/25924] Very poor choice of hash function in hsearch

["carlos at redhat dot com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=25924

Carlos O'Donell <carlos at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |carlos at redhat dot com
             Status|UNCONFIRMED                 |SUSPENDED
     Ever confirmed|0                           |1
           Severity|normal                      |enhancement
   Last reconfirmed|                            |2020-05-05

--- Comment #2 from Carlos O'Donell <carlos at redhat dot com> ---
I agree, there might be better hash implementations, but selecting one also
requires performance testing on the various architectures that glibc supports.
Therefore there are really many steps to getting performance related work
accepted in the project:

(1) Proof of performance for various architectures, or work with the
architecture maintainers to get them to run microbenchmarks for you.

(2) The patch, which has to follow our contribution checklist (more on that
later).

(3) Tests for the changes. Systems level work requires good testing.

Now back to the contribution checklist:

As a GNU project we have some specific copyright assignment requirements,
particularly:
https://sourceware.org/glib/wiki/Contribution%20checklist#FSF_copyright_Assignment
https://www.gnu.org/licenses/why-assign.en.html

You can see our full contribution checklist here:
https://sourceware.org/glibc/wiki/Contribution%20checklist

We want the original author of that code to disclaim or assign copyright to the
FSF for the project to use.

I'm going to move this feature request into SUSPENDED. We can move this out of
SUSPENDED if we have an implementation that can be assigned to the FSF for
glibc to use to improve the hash function.

-- 
You are receiving this mail because:
You are on the CC list for the bug.