Fixed marshalling of size_t into nuint instead of int. #197
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR fixes the issue of marshalling
size_tinto appropriately sized integers, as described in this issue.I went with the native
nuinttype, which should map 1-to-1 withsize_t.For the public API, I decided to cast the
nuintreturned bymdb_cursor_countto along, as this seems more idiomatic and convenient for users when dealing with counts. However, this is a breaking change, and if avoiding it is preferred then we could cast to anintinstead (but see below). I do think it makes sense to return alongthough, as (I assume) the underlying implementation supports having more than 2^32 duplicate entries in a database, in which case anintwould truncate the value.For the transaction id, on the other hand, I decided to propagate the
nuintto the public API. This seems like the safest option as it makes no assumptions on the possible values that can be returned by the C implementation. In principle one could probably cast safely to along, but as an identifier it isn't meant to be used in arithmetic operations anyhow. Either way, I think this needs to be a breaking change, as aninttransaction id is unsafe on platforms where the underlying implementation can return values greater than 2^32 - this can lead to id reuse, which could become a problem for long-running processes.