Improve ANSI and POSIX locale coverage and compliance.

[ikbenlike]

This issue is intended to give an overview of what is to be done to provide better coverage of the locale functionality as specified by POSIX. Due to the nature of the POSIX extensions it is almost inevitable some POSIX-related code will end up in the ANSI-option of mlibc, specifically in the implementation of setlocale().

• Improve setlocale()s standards compliance in regards to resolving the locale which is to be used, as per the introduction of this page and the end of section 8.2 of this page
• Properly implement the POSIX locale and the extra fields which aren't defined by ANSI
• Make setlocale() change POSIX-defined locale attributes on locale changes
• Implement nl_langinfo() and nl_langinfo_l()
• Implement newlocale(), freelocale(), uselocale() and duplocale()
• Provide an implementation of the locale utility, provided by glibc on linux
• Provide an implementation of the localedef utility, also provided by glibc
• Give locale functions the ability to read locales compiled by localedef

Implementing the libc functions listed here will allow us to close issues #53 and #323. It will also allow work necessary to close #276 to continue. Furthermore, it would allow us to implement many functions in ansi/string-stubs.cpp, as a lot of the currently unimplemented functions depend on locale functionality.

[Dennisbonke]

Keep in mind that the iconv utility is also provided by libiconv as far as I’m aware, so we need to make sure to gate it in the iconv option or we break at least Managarm, which doesn’t use the libc provided iconv functions, but opted to use libiconv instead

[ikbenlike]

Keep in mind that the iconv utility is also provided by libiconv as far as I’m aware, so we need to make sure to gate it in the iconv option or we break at least Managarm, which doesn’t use the libc provided iconv functions, but opted to use libiconv instead

That is good to know

[ArsenArsen]

leaving libiconv business out of libc is probably not a bad choice altogether

[Dennisbonke]

I’m inclined to agree, especially considering libiconv is a known working and complete implementation, but posix unfortunately specifies this so we have to provide it. I don’t plan on switching Managarm back to the libc provided versions, for me libiconv is fine, but other users may not want to use libiconv.

[ikbenlike]

leaving libiconv business out of libc is probably not a bad choice altogether

It would be necessary to provide it for POSIX-compliance, however I see little reason to stop using libiconv on managarm

[ArsenArsen]

POSIX compliance is not necessary, to my awareness there's no current system with full POSIX compliance. This arguably goes beyond the point of pragmatic choices.

Things like these are status quo, see libm on Linux for instance.

[ikbenlike]

I mean, it is possible for libm to just be empty and have the libc implement the maths functions. But if POSIX compliance is not an important aim there is very little reason to implement iconv, and removing it from this list is fine by me.

[no92]

I do not think the locale and localedef utilities are portable from glibc, and will probably just require a reimplementation.

The rest should be addressed by #1480.