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