Fix edge cases in code parser and stringifier (found by fuzzing) #7886
Conversation
- that is, a string (not) terminating with a slash.
oprypin
force-pushed
the
fuzz1
branch
2 times, most recently
from
95d8253
to
ee3b3d9
Compare
straight-shoota
added
kind:bug
|
It's failing though... Wasn't able to figure out ranges+newlines yet |
That is, very large integers *with* the suffix specified. It was unconditionally converting the value to uint64, but have to check for the validity of that first. Additional check for num_size < 20 fixes it. Such numbers definitely fit into uint64. And this condition fully covers int64, too. gen_check_uint_fits_in_size is not used for uint64 so this is fine.
Parsing/stringifying a macro body would always add two spaces and a newline, but it's supposed to stop changing after one pass.
|
Excluded the failing commit, will get back to that one later. |
|
(in another PR; so this one is ready) |
|
Thanks! Can the PR be named in a way it reflects the impact and no the procedure so it’s more meaningful as a changelog entry in the future? |
|
The commits are meaningful changelog entries, the PR is indeed arbitrarily grouped by procedure. |
oprypin
changed the title
|
I think Range and newline doesn't need to be supported because |
|
Alright, then I will not attempt to cover it. Seems consistent with the rest of the language, things like But still doing it in a separate PR. |
|
Yes, now I'm actually not sure, probably endless range only makes sense when |
|
Well then, good that I split out the controversial thing. |
|
Thank you @oprypin ! |
https://github.com/oprypin/crystal-fuzzing