clemg / pythongolfer Goto Github PK

Due to a broken check in the codegolf function, non-Latin-1 characters (all those above U+00FF) at odd-numbered positions in the input string have their code point silently truncated to 8 bytes, instead of throwing an error so the user can be notified.

To Reproduce

1. Enter 'ज़' into input box, which has a non-Latin-1 character in index 1.
2. Click on "Golf it" button
3. Observe printed output exec(bytes('嬧‧','u16')[2:])
4. Verify that bytes('嬧‧','u16')[2:] evaluates to b"'[' ", which does not match the input code.

Expected behavior
Error message displayed about non-ASCII characters, as it is for the input ' ज़' (space added to put the character into an even-numbered position).

Environment

• OS: Windows 10
• Browser: Brave Version 1.39.111 Chromium: 102.0.5005.61 (Official Build) (64-bit)

Additional context
The code causing the issue is here
Effectively c1 (the even-numbered character) is checked but c2 is ignored and subsequently truncated.

Also
Handling of characters from the Latin-1 Supplement block (U+0080 to U+00FF) by this site is unclear. These are non-ASCII characters, but is there a reason to ban them from the input? Shouldn't the check really be > 255 instead of > 127?

Describe the bug
When the input code contains ". ", the coating code is reversed and sometimes appears in the middle.
For some reasons, it does not happen every time, it depends on the position of the ". " string.

To Reproduce
Steps to reproduce the behavior:

1. Go to https://clemg.github.io/pythongolfer/
2. Enter a code with ". " in it
3. Click the "Golf it!" button
4. See error

Expected behavior
The result code should appear coated with the decoding python code, but instead we get a reversed string in the middle.

Screenshots

Desktop or Smartphone (please complete the following information):

• OS: Windows 10
• Browser Firefox
• Version 84.0.2 (64 bits)

Edit: also works with "+ " in it.
Theory: Maybe when the "+" or the "." is in an even indice position in the string, the converted char in UTF-16 is a reversing one, it would explain what this happens only in this precise case.