This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][RFC] Sanitize equals and hash functions in hash-tables.
- From: Alexander Monakov <amonakov at ispras dot ru>
- To: Martin Liška <mliska at suse dot cz>
- Cc: gcc-patches at gcc dot gnu dot org, Nathan Sidwell <nathan at acm dot org>, Jason Merrill <jason at redhat dot com>, Jakub Jelinek <jakub at redhat dot com>, Paul Richard Thomas <paul dot richard dot thomas at gmail dot com>, Martin Jambor <mjambor at suse dot cz>
- Date: Mon, 29 Oct 2018 16:53:29 +0300 (MSK)
- Subject: Re: [PATCH][RFC] Sanitize equals and hash functions in hash-tables.
- References: <23ffca95-6492-e609-aebb-bbdd83b5185d@suse.cz>
On Mon, 29 Oct 2018, Martin Liška wrote:
> My question is whether we want to have in GCC 9 time frame or should I wait with that?
> Does it worth implementing?
This is cool, thanks! A few questions/comments on the patch.
I think there are places that use libiberty C-style hashtab (htab_t), would it
make sense to have this kind of checking for them as well? I think it's going
to be more complicated though, no need to do both in one step.
I would recommend to factor out the error reporting path into a separate
non-template function, e.g. hashtab_chk_error. See how qsort_chk_error
has "cold" and "noreturn" attributes and invokes problematic comparators:
the idea was that a developer can 'break qsort_chk_error' in GDB and then
easily step into broken comparators.
Furthermore, it might be nice to investigate if the entire checking loop can
be factored out somehow into a non-template function to avoid having multiple
instantiations of it for different hashtable template parameters.
On my first attempt to submit qsort_chk, Richi asked how much it slows down
stage2, do you have some data on the cost of this hashtable checking?
I think it is possible to optimize this a bit: instead of checking on
insertions, check on deletions and when destroying the table (with care to do
n^2/2 rather than n^2 tests). Although, such approach would miss errors on
hashtables that are never destroyed (leaked or deliberately not deleted).
Alexander