Networking subsystem should not use extensions to the C library beyond the allowed subset

[aescolar]

Problem Description

Our coding guidelines limit what C library functions Zephyr code may use:
https://docs.zephyrproject.org/latest/contribute/coding_guidelines/index.html#rule-a-5-c-standard-library-usage-restrictions-in-zephyr-codebase
Today the networking code is using some extensions beyond this. This either limits the C library which can be used to one which supports this extensions, or requires enabling the POSIX_API subsystem (which should not be required by core Zephyr code).

Proposed Change

One way forward/option would be that

1. We locate all offending uses (for ex. after Networking subsystem should not (re)define C library types, macros or functions #97050 is solved, we (locally) build the networking subsystem ensuring we disable the POSIX subsystem and do not enable any of the feature test macros to enable extensions and see what breaks).
2. We add to this RFC the list of all offenders, and once we have done that we decide how to proceed for each.
3. Options may be to either:
   a) Eliminate the use where it can be replaced simply enough with standard functionality
   b) Accept that particular function use as an extra exception to rule Rule A.5: C, and provide it as an option from the common libc, which C libraries can enable if needed.
   c) Accept that particular function use, which is used from the POSIX subsystem if not provided by the C library, but ensure it is a clearly separate component which then networking would enable thru kconfig (without enabling/pulling anything else).
   d) ...

(Added 2025/10/31..) Known so far:

• https://github.com/zephyrproject-rtos/zephyr/blob/main/subsys/net/lib/http/http_server_core.c#L781
  utilizes fnmatch() which is a POSIX.1-2008, and FNM_LEADING_DIR which is a further GNU extension on this.
• Zephyr's not standard getopt*: Zephyr's "getopt" should become a separate component #98568
  • sys: getopt: Rename getopt to sys_getopt to avoid conflicts with Posix #98845
  • Clean a few sys_getopt global status variable uses after #98845 #99599
• eventfd: Way forward: Fix uses in core net code by using underlaying zvfs_eventfd
  • net: Replace Posix eventfd by zvfs_eventfd API #98765
  • subsys/net: Fix EVENTFD kconfig selection #99654
• Includes of unistd.h: Seem unnecessary. => We remove #include <unistd.h> lines from core net code.
• Uses of flags from fcntl.h: We have ZVFS_ prefixed versions we can use
  • net: Namespace network symbols to avoid conflicts with POSIX or libc #99169
  • net: Disable namespace compatibility support for tests  #99604
• Hostapp and WIFI_NM_WPA_SUPPLICANT using it. Most sensible way forward seems to be to accept it.
• Basic net samples like echo_client/server using posix interface instead of zephyr zsock_ interface

Dependencies

Networking, C library, POSIX_API/POSIX compatibility layer subsystem.

Additional info

This is related to but it is not the same than:

• Networking subsystem should not (re)define C library types, macros or functions #97050
• Zephyr's "getopt" should become a separate component #98568

[rlubos]

c) Accept that particular function use, which is used from the POSIX subsystem if not provided by the C library, but ensure it is a clearly separate component which then networking would enable thru kconfig (without enabling/pulling anything else).

That appears to me as the most reasonable approach at least for the reported case (fnmatch() use in HTTP server library).

HTTP server is a totally optional component, not a dependency for any other part of the networking subsystem so IMHO there's nothing wrong for it to have a dependency to some part of the POSIX subsystem enabling required functionality (said fnmatch()).

If we can copy that function out of POSIX and provide it as a libc extension, fine, but it seems like an unneeded hassle to me. Reimplementing such a complex functionality at the HTTP lib level just for the sake of not having POSIX dependency sounds simply wrong to me.

[cfriedt]

HTTP server is a totally optional component, not a dependency for any other part of the networking subsystem so IMHO there's nothing wrong for it to have a dependency to some part of the POSIX subsystem enabling required functionality (said fnmatch()).

All that is needed for fnmatch() is CONFIG_POSIX_C_LIB_EXT=y. The same is true for strnlen().

Similarly, all that is needed for gmtime_r() and strtok_r() is CONFIG_POSIX_C_LANG_SUPPORT_R.

If we can copy that function out of POSIX and provide it as a libc extension, fine, but it seems like an unneeded hassle to me. Reimplementing such a complex functionality at the HTTP lib level just for the sake of not having POSIX dependency sounds simply wrong to me.

It is already a (POSIX) libc extension, and shouldn't be "copied out of POSIX" (I assume this means lib/posix), since it is specified by POSIX, and not by the ISO C standard.

https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3220.pdf (fnmatch() and strtok_r() are clearly absent from the standard)

On the other hand, gmtime_r() has been "copied out of POSIX" by ISO C standard as of revision C23.
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3220.pdf (gmtime_r() is clearly part of the standard, Annex K)

Note also that POSIX extensions to the standard C library (i.e. the POSIX_C_LIB_EXT Option Group) are available without enabling CONFIG_POSIX_SYSTEM_INTERFACES (i.e. those POSIX interfaces that require OS support).

https://github.com/zephyrproject-rtos/zephyr/tree/main/lib/posix/c_lib_ext

which is really how it should be done.

The advantage of using this method is that, in combination with CONFIG_POSIX_C_LANG_SUPPORT_R, all of the requirements of our coding guidelines are already captured without having to make exceptions to any standard and add yet more technical debt.

Any toolchain is able to provide the POSIX_C_LIB_EXT Option Group, just as any toolchain is able to provide the POSIX_C_LANG_SUPPORT_R Option Group (via CONFIG_TC_PROVIDES_...).

NOTE

Our coding guidelines limit what C library functions Zephyr code may use...

... requires enabling the POSIX_API subsystem (which should not be required by core Zephyr code).

The description of this issue is very misleading. It certainly does involve POSIX functions, and not "C library functions". We should be very careful as to not selectively misinterpret standards. Additionally, all of the actual (POSIX) C library extensions that Zephyr depends on are already available today without enabling CONFIG_POSIX_API. This should be very obvious to @aescolar since he created this issue on the same day that he reviewed #97855 (on the day of the feature freeze), which deprecates CONFIG_POSIX_API.

Luckily, I found this ticket and was able to correct some of the inaccuracies early. I added the POSIX label because it was notably absent.