release/v2.0.1#7
Conversation
|
We should investigate how we want to go about replacing the asserts. Some cases returning NULL, 0, etc may be appropriate or calling abort() may be the appropriate. |
GJames-RiversideResearch
left a comment
There was a problem hiding this comment.
I think utilizing a fixed size data structure instead of size_t could be valuable and we should also consider keeping in asserts for debug builds to give rich error messages
|
Thanks for your feedback @jhjones-riverside and @GJames-RiversideResearch. I agree that a blanket silent-fail approach isn't ideal. I'm thinking of adding a |
GJames-RiversideResearch
left a comment
There was a problem hiding this comment.
Comments have been adressed, happy with the changes
GJames-RiversideResearch
left a comment
There was a problem hiding this comment.
Looks good with 1 slightly pedantic comment
HToken.lenandbits_env.lengthfromuint8_ttosize_t, fixing Integer Truncation in h_token Allows Parser Bypass (/src/parsers/token.c) #3.h_bits(264, false)no longer silently wraps toh_bits(8, false). ForHToken,sizeof(HToken)is unchanged on common targets as the trailing struct padding absorbs the difference.HAMMER_ASSERTininternal.hand replaceassert()-based programmer-error guards acrossbitwriter.c,glue.c,glue.h, anddatastructures.c, closingassert()used as sole input validation which is silently disabled under-DNDEBUG#6. Unlikeassert(),HAMMER_ASSERTalways aborts regardless of-DNDEBUG. Runtime boundary conditions such as thesloballocsize check retain explicit safe returns.h_assert_typemacro to useHAMMER_ASSERT, aborting on type mismatch in all builds.test_token_len_assertto reflect the new behavior: tokens longer than 255 bytes are now valid, and the test verifies a 256-byte token parses correctly end-to-end.rufflinting of Python and SCons files to the CI pipeline alongside other formatting checks before thebuild-debstep.