Check the specification at http://clhs.lisp.se/Body/f_mk_has.htm http://clhs.lisp.se/Body/f_mk_has.htm

Specifically, size is a hint to the implementation http://clhs.lisp.se/Body/26_glo_i.htm#implementation about how much initial space to allocate in the hash-table. This information, taken together with the rehash-threshold, controls the approximate number of entries which it should be possible to insert before the table has to grow. The actual size might be rounded up from size to the next `good' size; for example, some implementations http://clhs.lisp.se/Body/26_glo_i.htm#implementation might round to the next prime number.

So I’d say it is not a bug.

On 30 Mar 2022, at 05:34, Johnny Ruiz jeko2000@yandex.com wrote:

Hello,

This is to report a possible bug in ABCL v1.8.0. When I create a new hash table and pass an initial size of a number lower then 11 (e.g., 7), the function hash-table-size reports the size as 11 instead of the provided size.

$ abcl --noinit Armed Bear Common Lisp 1.8.0 Java 18 Homebrew OpenJDK 64-Bit Server VM Low-level initialization completed in 0.092 seconds. Startup completed in 0.471 seconds. Type ":help" for a list of available commands. CL-USER(1): (defparameter *hash-table* (make-hash-table :size 7)) *HASH-TABLE* CL-USER(2): (hash-table-size *hash-table*) 11 CL-USER(3):

As long as :size is 11 or higher, then hash-table-size reports the expected size.

CL-USER(3): (defparameter *larger-hash-table* (make-hash-table :size 42)) *LARGER-HASH-TABLE* CL-USER(4): (hash-table-size *larger-hash-table*) 42

Is this a known issue? Reference: https://github.com/jeko2000/synchronized-hash-tables/issues/3 https://github.com/jeko2000/synchronized-hash-tables/issues/3 -- Thank you, Johnny Ruiz