Conversation
|
I think while your reasoning here makes sense for the octal int literal In a C string you would for example write: char str[] = "\377\377\377\0";with a readable Nushell equivalent: let str = 0o[377 377 377 000] # Note that you currently need to pass multiples of three for the octal coded byte string which makes the chunking consistentIf you want to express the carrying single int semantics you have the |
|
Oh yeah, mb I thought Maybe a more reasonable thing to do is to throw an error (with better error message) if a chunk of 3 is out-of-range? |
|
The error message can definitely be improved, I think it shouldn't fall back to immediately treating it as a command if you make a simple syntax error in such a unique syntax construct. |
|
For reference the motivating example in the top description can be achieved by: (0o71777342767 | into binary --endian big --compact) == 0b[111 001 111 111 111 011 100 010 111 110 111] |
|
Alright, I'll close this PR and open up a new PR for improved error message. Should I also include an error message for non-multiples of 3 for octals and other invalid strings such as |
That sounds wonderful! I think you don't have to fully distingquish between all the different variants in the error message and only report the expectations in one error message if that isn't too bad. |
Fixes #9566. Based on the decision from this PR #16678, instead of dealing with out-of-range octal strings, throwing a specific error is better. Let me know if these error messages are too detailed and prefer just having a single "out-of-range error". ## Release notes summary - What our users need to know Previously, a generic shell error is thrown for invalid binary strings. Now, an improve error message is thrown for invalid binary, hexadecimal, and octal strings. ```nushell > 0b[121] # => Error: nu::parser::invalid_binary_string # => # => × Invalid binary string. # => ╭─[entry #1:1:1] # => 1 │ 0b[121] # => · ───┬─── # => · ╰── invalid binary string # => ╰──── # => help: binary strings may contain only 0 or 1. ``` ## Tasks after submitting - N/A
Fixes #9566.
Binary and hexadecimal strings have no issues in parsing because they are parsed at a chunk of 8 characters (max of
11111111or 255 in decimal) and 2 characters (max ofFFor 255 in decimal). However, for octals this is not the case, previously it was chunked by 3 characters (max of777which is 511 in decimal hence it exceedsu8::MAX).I solved this by not chunking at all and instead parse the entire octal string as
u128. Chunking will never work for octals since there isn't an exact number of chars that will fit exactly up to 255.To see if it works, you can try this and it should parse & return true:
Release notes summary - What our users need to know
Fixed parsing for octal strings. Previously, only octal strings up to
0o[377]was allowed. Now, any octal strings can be parsed properly.Tasks after submitting
N/A