Closed graphitemaster closed 9 years ago
Querying the size of elements in most of these containers all return uint32_t
as well. Making them use size_t
instead. As well as for indices would make this code much more scale-able for different architectures and more correct.
ok for the vlen member in the tagged_value_t to be size_t ... but I think that changing the whole api in all the containers to return 'their capacity' as size_t instead of uint32_t seems a bit overkill and not necessary.
Anyway, apart for tagged values in linkedlists, where do you see other size members being uint32_t ? I see that all the other containers already use size_t for size members ... linkedlist was written long time ago and probably wasn't fully updated when imported in libhl.
The only thing I see being uint32_t across all the containers is the 'number of elements that will fit in the container'
6dbe9834112d9ba08b271dc08bc4a13919028476
actually , after giving a closer look, changing the capacity of all containers (and hence the position indices for linkedlist) and the relative API to use size_t instead of uint32_t seems pretty trivial. I might consider such a change at some point.
Currently the tagged value structure for linked lists assumes that the length of a value can fit inside uint32_t. While I'd agree that value types larger than 0xffffffff bytes are pathological; use of size_t instead is of no harm and does not blindly break the interface contract of
strlen
and would allow you to remove the cast on this line in particularnewval->vlen = (uint32_t)strlen((char *)val);
.When representing the size of something it's always best to use
size_t
which is specifically guaranteed to be large enough to hold the size of any represent-able allocation or object in memory. This is why allocation functions expectsize_t
, whystrlen
returns it and why thesizeof
operator does as well.