minimal libc + posix: add strerror and perror functions

[cfriedt]

Add basic strerror() and perror() implementations to the minimal C library.

Also add myself as collaborator in that area.

With a simple change to samples/hello_world, we observe the following size differences on cortex-m3:

Before change:

Memory region         Used Size  Region Size  %age Used
           FLASH:        8576 B       256 KB      3.27%

After change (CONFIG_MINIMAL_LIBC_STRING_ERROR_TABLE=n):

Memory region         Used Size  Region Size  %age Used
           FLASH:        8576 B       256 KB      3.27%

After change (CONFIG_MINIMAL_LIBC_STRING_ERROR_TABLE=y):

Memory region         Used Size  Region Size  %age Used
           FLASH:       10852 B       256 KB      4.14%

Fixes #46099
Fixes #46100

[cfriedt]

Coding guideline issues are a false positive

[stephanosio]

Need to update https://github.com/zephyrproject-rtos/zephyr/blob/main/doc/services/portability/posix.rst as well.

Also as per #45776 and the previous discussion on the scope of the minimal libc, I am not convinced this should be a part of the minimal libc because:

1. The original intent of the minimal libc was to provide only the minimal amount of functions required to make Zephyr run for testing and validation as per @nashif's comments in the linked discussion.
2. These functions are not required by any of the Zephyr internal components.
3. We will be moving on to using the picolibc as the default C library instead of the minimal libc in the near future, in which case the latter will be reserved only for internal testing and validation purposes and will not be used by end users/products.

Nevertheless, I am not necessarily opposed to merging this because we have added other "non-essential" features to the minimal libc before, and this feature can be configured such that it does cause any meaningful footprint increase.

[cfriedt]

Need to update https://github.com/zephyrproject-rtos/zephyr/blob/main/doc/services/portability/posix.rst as well.

Good catch - will do.

Also as per #45776 and the previous discussion on the scope of the minimal libc, I am not convinced this should be a part of the minimal libc because:

1. The original intent of the minimal libc was to provide only the minimal amount of functions required to make Zephyr run for testing and validation as per @nashif's comments in the linked discussion.

Yes, definitely.

Another aspect about the minimal libc, was to minimize the amount of maintenance necessary as well. This implementation of strerror() requires only a negligible amount of maintenance. Quite literally just maintaining errno.h, which is something we do already.

I can definitely see the frustration about manually maintaining a separate table of error strings that would rely on a human to remember to update. At least this way it's minimal in that sense.

2. These functions are not required by any of the Zephyr internal components.

Note: perror() is a PR to lib/posix and not to the libc. It's a common function used on posix systems and references strerror() in most implementations. If perror() exists, then most likely strerror() would exist as well. I would suggest using a Kconfig regardless of the libc though to explicitly include the error string table.

3. We will be moving on to using the picolibc as the default C library instead of the minimal libc in the near future, in which case the latter will be reserved only for internal testing and validation purposes and will not be used by end users/products.

That works for me too - I would make this PR to picolibc as well, if it does not already have strerror().

I wouldn't necessarily say with absolute certainty that users/products will not use the minimal libc though. If it's in-tree (rather than a module) that might be enough for some organizations to stick with it, as the cost of adding / updating another repo is large in comparison.

Nevertheless, I am not necessarily opposed to merging this because we have added other "non-essential" features to the minimal libc before, and this feature can be configured such that it does cause any meaningful footprint increase.

Thanks. Yeah, I thought that would be a concern for sure, and so wanted to make the default "no code size increase".

[cfriedt]

Looks like some CI issue atm - will see if I can re-run


.

[stephanosio]

Looks like some CI issue atm - will see if I can re-run

Yea, GitHub is having (yet another) bad day.

https://discord.com/channels/720317445772017664/733037738068148335/991718319310766090

[cfriedt]

@keith-packard - could use your review here as well

[keith-packard]

Let's have the strings present by default so that naive apps 'just work'.

[cfriedt]

Let's have the strings present by default so that naive apps 'just work'.

@keith-packard - I've flipped and I've flopped already. Am going to go with the maintainer's request here.

#46101 (comment)

[cfriedt]

• rebase / resolve conflicts in tests/lib/c_lib/testcase.yaml after lib/picolibc: Rework malloc arena setup #46969

@stephanosio, @keith-packard - please re-ack :-)

[carlescufi]

@keith-packard can you please re-approve?

[keith-packard]

lgtm.