Use pathbuffer reduce stack

[crafcat7]

Summary

Why is this change necessary?
Benefit from the lib_pathbuffer feature introduced in #12969, we can further optimize the stack usage size in the NuttX kernel.
Changes
In this change, we replaced the declarations related to xxx[PATH_MAX] in the NuttX directory with the lib_pathbuffer method

Impact

Is a new feature added?: NO
Impact on build: NO
Impact on hardware: NO, this change does not specifically target any particular hardware architectures or boards.
Impact on documentation: NO,This patch does not introduce any new features
Impact on compatibility: This implementation aims to be backward compatible. No existing functionality is expected to be broken.

Testing

Build Host(s): Linux x86
Target(s): sim/nsh

By default

LIBC_MAX_PATHBUFFER = 2
LIBC_PATHBUFFER_MALLOC = y

So when there is not enough memory on the stack, it will be requested from the heap

[nuttxpr]

[Experimental Bot, please feedback here]

Yes, this PR appears to meet the NuttX requirements based on the provided information. However, there are a couple of minor improvements that could be made to strengthen the testing section.

While the PR states testing was done on sim/nsh, the "Testing logs before change" and "Testing logs after change" sections are empty. Providing concrete examples of the stack usage before and after the change would significantly improve the review process. For example, showing the output of a command that displays stack usage, or even a code snippet demonstrating how the stack size was measured would be beneficial. This would provide concrete evidence of the optimization.

[anchao]

Since CONFIG_PATH_MAX can define a smaller size. let us add a configure CONFIG_LIBC_PATHBUFFER to enable/disable lib_get_pathbuffer implement.

#ifdef CONFIG_LIBC_PATHBUFFER
FAR char *lib_get_pathbuffer(void);
#else
#  define lib_get_pathbuffer() alloca(PATH_MAX)
#endif

[xiaoxiang781216]

alloca isn't ANSI or POSIX Api, so it isn't available on all possible compiler, and should disable by default.

[anchao]

Current code base:
https://github.com/apache/nuttx/blob/master/include/string.h#L40-L51

I think most toolchains support this feature (even MSVC has a similar implementation)
https://github.com/apache/nuttx/blob/master/include/alloca.h#L30-L42

[crafcat7]

I submitted a fix for the redefinition problem in libc under kernel build when using ffs/ffsl/ffsll.
a9e1d1b

[crafcat7]

There is a ld problem here, I found that the static always inline ffs function implementation exists in the compilation expansion, but it cannot find the builtin ffs in the final link.

I tried changing the ffs part to __builtin_ffs in the code, but it still prompted an undefined reference to `ffs'.
Similarly, using ctz / __builtin_ctz / ffsl / __builtin_ffsl / ffsll / __builtin_ffsll does not have this problem

It seems that the implementation of _builtin_ffs cannot be found.

So is there any good way to solve this problem? Or should we add more restrictions to the implementation of builtin_ffs?

riscv-none-elf-ld: /github/workspace/sources/nuttx/staging/libc.a(lib_pathbuffer.o): in function `lib_get_pathbuffer':
/github/workspace/sources/nuttx/libs/libc/misc/lib_pathbuffer.c:89:(.text.lib_get_pathbuffer+0x1c): undefined reference to `ffs'
make[1]: *** [Makefile:189: nuttx] Error 1
make: *** [tools/Unix.mk:551: nuttx] Error 2