Make internal usage of uint32_t more explicit#131
Open
pgaskin wants to merge 2 commits intos-yata:masterfrom
Open
Make internal usage of uint32_t more explicit#131pgaskin wants to merge 2 commits intos-yata:masterfrom
pgaskin wants to merge 2 commits intos-yata:masterfrom
Conversation
This will warn on things like implicitly converting a size_t to uint32_t.
pgaskin
changed the title
pgaskin
force-pushed
the
grimoire-uint32
branch
from
a2bf37f to
bad5374
Compare
This was referenced Nov 5, 2025
This change will not break the public API/ABI. It only affects the data structures used internally which already contain unconditional asserts or narrowing casts for UINT32_MAX (but not the ones which have a MARISA_THROW_IF for a length_error). Most of those already use uint32_t variables internally after the case, and only take/return size_t in the getters/setters. Where lengths/indexes are computed at runtime, I continue to use size_t, then assert and cast it to a uint32_t afterwards. I also kept size_t for I/O. I modified Vector/FlatVector to limit itself to UINT32_MAX instead of SIZE_MAX (and check it when reading) since it's already effectively limited to that anyways.
pgaskin
force-pushed
the
grimoire-uint32
branch
from
bad5374 to
512b856
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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 change will not break the public API/ABI.
It only affects the data structures used internally which already contain unconditional asserts or narrowing casts for UINT32_MAX (but not the ones which have a MARISA_THROW_IF for a length_error).
Most of those already use uint32_t variables internally after the case, and only take/return size_t in the getters/setters.
Where lengths/indexes are computed at runtime, I continue to use size_t, then assert and cast it to a uint32_t afterwards. I also kept size_t for I/O.
I modified Vector/FlatVector to limit itself to UINT32_MAX instead of SIZE_MAX (and check it when reading) since it's already effectively limited to that anyways.