Author vstinner
Recipients colesbury, gregory.p.smith, serhiy.storchaka, vstinner
Date 2020-04-01.13:41:27
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1585748487.82.0.154298244226.issue40120@roundup.psfhosted.org>
In-reply-to
Content
Modules/hashtable.c and Modules/hashtable.h use a different approach. The variable size data is *not* part of the structure:

typedef struct {
    /* used by _Py_hashtable_t.buckets to link entries */
    _Py_slist_item_t _Py_slist_item;

    Py_uhash_t key_hash;

    /* key (key_size bytes) and then data (data_size bytes) follows */
} _Py_hashtable_entry_t;

In memory, we have: [_Py_slist_item, key_hash, key, data] where key size is table->key_size bytes (not stored in each table entry, only in the stable).

Pointer to key and data is computed with these macros:

#define _Py_HASHTABLE_ENTRY_PKEY(ENTRY) \
        ((const void *)((char *)(ENTRY) \
                        + sizeof(_Py_hashtable_entry_t)))

#define _Py_HASHTABLE_ENTRY_PDATA(TABLE, ENTRY) \
        ((const void *)((char *)(ENTRY) \
                        + sizeof(_Py_hashtable_entry_t) \
                        + (TABLE)->key_size))

But this approach is more annoying to use, it requires to play with pointers and requires such ugly macros.
History
Date User Action Args
2020-04-01 13:41:27vstinnersetrecipients: + vstinner, gregory.p.smith, serhiy.storchaka, colesbury
2020-04-01 13:41:27vstinnersetmessageid: <1585748487.82.0.154298244226.issue40120@roundup.psfhosted.org>
2020-04-01 13:41:27vstinnerlinkissue40120 messages
2020-04-01 13:41:27vstinnercreate