feat(stdlib): strncpy consistency and add strlcpy

[liamHowatt]

Description of the feature or fix

Following up with the discussion about strncpy in #5927

Make lv_strncpy consistent with the standard spec.

The standard spec of strncpy isn't necessarily better than the one that's implemented in LVGL lv_string_builtin.c. The concern is that the behavior of lv_strncpy changes depending on the configured LV_USE_STDLIB_STRING. We wrap the libc strncpy with the modified behavior to match the unique builtin behavior, however we don't wrap the rt-thread implementation and the rt-thread implementation matches the standard spec, i.e. the libc behavior.

I updated the uses of lv_strncpy where it's called to ensure a null terminator is added where it's expected.

See the manpage for strncpy.

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 version v3.4.12 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]

I feel like our behavior for lv_strncpy is better 🤣 I really can't understand why the standard is filling all the remaining place with zeros and doesn't ensure null termination.

So I would rather make RT-Thread's (ad the others') implementation like ours because this way we need to make this only a few places instead of in the whole code base where contributors might forget adding the closing zero.

[XuNeo]

I feel like our behavior for lv_strncpy is bette

You are looking for strlcpy. Let's use lv_strlcpy then. The standard is fixed, we cannot do much about it now.

I didn't realize we could use strlcpy instead until recently :(

[kisvegabor]

I didn't know strlcpy either, but it's great! I agree to use lv_strlcpy. @liamHowatt if you also agree could you update this PR accordingly?

[liamHowatt]

I agree. I'll add strlcpy and use it in most places strncpy is.

[liamHowatt]

Updated.

So it looks like the strlcpy is a BSD thing. You need libbsd installed. So I just implemented the clib one in terms of strlen and memcpy so people using clib string don't need libbsd.

FYI strlcpy returns the length of src. Something to note.

[XuNeo]

Thank you!

[kisvegabor]

Thank you!

I'm not sure we need to keep lv_strncpy but let's leave it for backward compatibility.

[kdschlosser]

@kisvegabor

I think this is the one that broke the MicroPython CI.

The rest relies on loading fonts from the file system and this change specifically alters the file system drivers...

[liamHowatt]

That CI was run before this got merged.

[kdschlosser]

There are only 2 things that got merged in that time frame and this is the only one that would effect the micropython CI

Maybe something got changed over in the micropython binding?

[kdschlosser]

nothing changed over there either. Gonna have to turn on debugging for the test to see what is happening.