u-boot.git/test/common/cread.c, branch v2023.07.01Unnamed repository; edit this file 'description' to name the repository.http://cgit.235523.xyz/u-boot.git/atom/test/common/cread.c?h=v2023.07.012023-03-28T13:25:51Zcli: Correct handling of invalid escape sequences in cread_line()2023-03-28T13:25:51ZSimon Glasssjg@chromium.org2023-03-27T19:34:14Zurn:sha1:be0169f07e38b81dd96bca2e80610592d89f8550
The second call to cli_ch_process() is in the wrong place, meaning that
the one of the characters of an invalid escape sequence is swallowed
instead of being returned.
Fix the bug and add a test to cover this.
This behaviour matches that of the code before cli_getch() was
introduced. This was verified on the commit before b08e9d4b66 i.e.:
7d850f85aad ("sandbox: Enable mmc command and legacy images")
Signed-off-by: Simon Glass <sjg@chromium.org>
Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
cli: Correct several bugs in cli_getch()2023-03-28T13:25:51ZSimon Glasssjg@chromium.org2023-03-27T19:34:13Zurn:sha1:17b45e684af98c1cf37648ad05a98d500b367c5a
This function does not behave as expected when unknown escape sequences
are sent to it:
- it fails to store (and thus echo) the last character of the invalid
sequence
- it fails to set esc_len to 0 when it finishes emitting the invalid
sequence, meaning that the following character will appear to be part
of a new escape sequence
- it processes the first character of the rejected sequence as a valid
character, just starting the sequence all over again
The last two bugs conspire to produce an "impossible condition #876"
message which is the main symptom of this behaviour.
Fix these bugs and add a test to verify the behaviour.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de>