Indeed, the solution cannot be done directly within readU32FromCharChecked(),
because this function is used to read unsigned integers from the command line
in both short command (typically one letter) and --long-command= scenarios.
Erroring on wrong suffixes only makes sense in the case of the --long-command= scenario
because short commands are allowed to stack up (for example -bi7S is valid).

The --long-command= scenario happens in 6 places,
and the logic is abstracted behind the macro NEXT_UINT32().

I believe your fix is correct, but it's written directly to serve --memory= and --memlimit=, and therefore limited to these cases.

If you update NEXT_UINT32() with your corrected logic, you would fix all current and future usages of numeric parameters in --long-command= scenarios.

@ctkhanhly - if you have some time it'd also be useful to get the same treatment for the fields that directly use readSizeTFromChar.
The solution I'd opt for in this case is to create a NEXT_TSIZE that'd be the same as NEXT_UINT32 only it'd call readSizeTFromChar instead of readU32FromChar and use it for these fields.

I see a remaining test issue in mingw-long-test (CI).

It looks completely unrelated to this PR.
Maybe the compiler version changed for example, introducing a new warning which is flagged as an error in this test.

Anyway, I think you can safely ignore it, we'll deal with it separately.

Thanks @ctkhanhly , great bootcamp contribution !