Inconsistent parsing and/or evaluation for negative u64.
#1161
Assignees
Labels
Comments
johnchandlerburnham
added a commit
that referenced
this issue
Feb 24, 2024
- merges previous parse_num and parse_uint into a single parse_numeric - removes bounds check on Num, so that parsing numbers larger than the field will modularly wrap - corrects uint parsing so that we never accidentally parse uints as nums - implements a placeholder syntax for i64 for parsing twos-complement numbers (i.e. -1i64 parses to u64::MAX). In future this syntax should parse to a new literal type - add placeholder parsing for u8, u16, u32, u128, i8, i16, i32, i128 literals so that we correctly error that these have yet to be implemented - adds unit tests to ensure correctness of the above
github-merge-queue bot
pushed a commit
that referenced
this issue
Feb 25, 2024
* new numeric parser, closes #609, #1161, #1169 - merges previous parse_num and parse_uint into a single parse_numeric - removes bounds check on Num, so that parsing numbers larger than the field will modularly wrap - corrects uint parsing so that we never accidentally parse uints as nums - implements a placeholder syntax for i64 for parsing twos-complement numbers (i.e. -1i64 parses to u64::MAX). In future this syntax should parse to a new literal type - add placeholder parsing for u8, u16, u32, u128, i8, i16, i32, i128 literals so that we correctly error that these have yet to be implemented - adds unit tests to ensure correctness of the above * clippy * clippy part II: revenge of the linter * remove unused byte parsers and associated tests * comment out printlns
|
Closed by #1171 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Something is wrong with the reading and subsequent handling of negative (Lurk)
u64s.A naked read yields a result obviously larger than
u64. This result appears to just be the correspondingNum(see example below).However, attempting to perform a computation on the expression yields an error — whereas using the corresponding
Numdoes not.I suspect we are creating an illegal value — perhaps tagged as
u64but with a value out of range for that type.Most importantly, this behavior should be consistent. Intuitively, although a bit weird,
-1u64should probably just be syntax for0xFFFFFFFFFFFFFFFF. That would be the most useful result. Alternately, we might decide this should be a parsing error.Whatever we do, the current state is a bug.
The text was updated successfully, but these errors were encountered: