Using next highest prime breaks hash table rename.

While trying to rename a hash table with a script, I discovered this bug:

http://hawkee.com/snippet/5493/ - lines 221 - 230

Code

; /hrename-prime test-old test-new
alias hrename-prime {
  var %t1 = $1, %t2 = $2

  if ($hget(%t1)) { hfree %t1 }
  hmake %t1 10000
  hadd %t1  abc def

  if ($hget(%t2)) { hfree %t2 }
  ; This fails because the $hget(%t1).size is over 10000
  ; * /hmake: invalid parameters (line 12, remote.ini)
  hmake %t2 $hget(%t1).size

  var %x = $hget(%t1,0).item
  while (%x) {
    hadd %t2 $hget(%t1,%x).item $hget(%t1,%x).data
    dec %x
  }
  hfree %t1
}

Another rename script:

https://forums.mirc.com/ubbthreads....y-rename-copy-hash-tables-ite#Post184894

This could be fixed by my request here
https://forums.mirc.com/ubbthreads....t-save-items-in-correct-order#Post264078
that the max buckets of 10000 be increased to 10007 to match the max value returned by $hget(tablename)

The last 2 primes used by /hmake are 9973 and 10007, with the max input accepted as 10000. This means using input in the range 9974-10000 generates a table using 10007 buckets, which is an error when trying to use $hget(table) to clone to another table.

I assume the 10000 is an arbitrary limit, as a more relevant max would be the largest prime less than 2^14 as 16381, but that might be too much of a jump.

Thanks for your bug report. This issue has been fixed in the next version. I have changed /hmake to determine the maximum allowed size by calling the same prime extension function used later on when the hash table is created. This should ensure that if the function is later changed, /hmake will still use the maximum value allowed by it.