Fix accepted chars issue on big endian systems

[jimbom]

Fixes: #5454

Description of the feature or fix

When adding accepted chars to a textarea, no characters are accepted on big-endian systems.

In the function lv_textarea_add_char, the character to add is taken as a uint32_t parameter, called c. When encoded, this is casted to a char pointer. On big endian systems this pointer will point to the wrong byte in the uint32_t, and the wrong encoded character, c_uni, will be used when checking for valid characters.

The root of the issue is the following line:
uint32_t c_uni = _lv_txt_encoded_next((const char *)&c, NULL);

The reference to uint32_t c should not be casted to a char pointer. To change this, I believe require pretty big changes to the code, since _lv_txt_encoded_next requires a const char *.

The solution/workaround made here is to swap the byte order of, c in case of big-endian system. But if lv_textarea_add_char is called from lv_textarea_add_text, the byte order of c is already correct, so then the bytes order shall not be swapped. Here we assume that the byte order shall be swapped if the most significant byte of c is zero. This worked in my case but will not give the correct value of c_uni if c is a 4 byte code. However, since I believe accepted characters will always be a char, I think this will never be an issue.

Notes

• Update the Documentation if needed.
• Add Examples if relevant.
• Add Tests if applicable.
• If you added new options to lv_conf_template.h run lv_conf_internal_gen.py and update Kconfig.
• Run scripts/code-format.py (astyle needs to be installed) and follow the Code Conventions
• Mark the Pull request as Draft while you are working on the first version, and mark is as Ready when it's ready for review.
• When changes were requested, re-request review to notify the maintainers.
• Help us to review this Pull Request! Anyone can approve or request changes.

[kisvegabor]

Thank you! it's great that v9 is tested on a Big endian machine too.

[kisvegabor]

Thank you! 👏