apps/system: replace CONFIG_NSH_LINELEN to LINE_MAX

[anchao]

Summary

1. apps/system: replace CONFIG_NSH_LINELEN to LINE_MAX

Applications should not depend on any properties of nshlib

Signed-off-by: chao an anchao@lixiang.com

2. nshlib/nshline: move all temp line buffer to heap

Signed-off-by: chao an anchao@lixiang.com

3. nshlib/traceline: move traceline buffer from stack to heap

Signed-off-by: chao an anchao@lixiang.com

Impact

N/A

Testing

sim/nsh ostest

[nuttxpr]

[Experimental Bot, please feedback here]

No, this PR does not fully meet the NuttX requirements. While it provides a summary of changes, it lacks crucial details.

Here's a breakdown of what's missing:

• Insufficient Summary: The summary lists what was changed but not why. It needs to explain the rationale behind replacing CONFIG_NSH_LINELEN and moving buffers to the heap. What problem does this solve? What are the benefits? There's no mention of a related NuttX issue.
• Missing Impact Assessment: Simply stating "N/A" for impact is insufficient. Even seemingly small changes can have unforeseen consequences. The PR needs to explicitly address each impact area (user, build, hardware, documentation, security, compatibility). For example, moving buffers to the heap could impact memory usage. This needs to be acknowledged and discussed.
• Inadequate Testing Information: "sim/nsh ostest" is not enough. The PR needs to specify the host operating system, CPU architecture, and compiler used for testing. It also needs to specify the target architecture and board configuration used with the simulator. Most importantly, it's missing the actual testing logs before and after the change, which are crucial for demonstrating that the changes work as intended and don't introduce regressions.

Example of how to improve the PR:

Summary:

This PR addresses potential buffer overflows and improves portability in nshlib and related applications. Applications were depending on the internal CONFIG_NSH_LINELEN setting from nshlib, which is not ideal for modularity. This PR replaces the use of CONFIG_NSH_LINELEN with the standard LINE_MAX define in applications. Additionally, temporary line buffers in nshlib/nshline and nshlib/traceline are moved from the stack to the heap. This prevents potential stack overflows when processing very long lines and improves the robustness of nshlib.

Related NuttX Issue: (If one exists, link it here)

Impact:

• Impact on user: YES. Applications using CONFIG_NSH_LINELEN will need to be recompiled. This should be a straightforward change, as LINE_MAX is a standard define.
• Impact on build: NO.
• Impact on hardware: NO.
• Impact on documentation: YES. Documentation should be updated to reflect the removal of the CONFIG_NSH_LINELEN dependency and the change to heap-allocated buffers. (Indicate if documentation changes are included in the PR).
• Impact on security: YES. This change mitigates potential stack overflow vulnerabilities when processing long lines.
• Impact on compatibility: Potentially backwards compatible with applications that don't use extremely long lines. However, applications directly relying on CONFIG_NSH_LINELEN will need modification.
• Anything else to consider: The change to heap-allocated buffers might slightly increase heap memory usage.

Testing:

• Build Host: Linux (Ubuntu 20.04), x86_64, GCC 9.4.0
• Target: sim:qemu-x86_64:nsh

Testing logs before change:

(Paste actual logs here showing the problem being addressed)

Testing logs after change:

(Paste actual logs here demonstrating the correct behavior after the change)

[xiaoxiang781216]

but this will increase the heap consumption for the temp use case.

[anchao]

Compared with irregular heap access, shared template and will make it more deterministic

[xiaoxiang781216]

could you split the rename from moving buffer to nsh_vtbl?

[xiaoxiang781216]

the temp buffer is only used in few command, why move it to nsh_vtbl to extend the life to the whole session?

[xiaoxiang781216]

but traceline is used only when launching program, isn't good to keep the buffer in the whole nsh life cycle

[xiaoxiang781216]

the temp buffer is only used in few command, why move it to nsh_vtbl to extend the life to the whole session?

[xiaoxiang781216]

let's remove CONFIG_NSH_LINELEN directly

[cederom]

Thank you @anchao :-) My questions:

1. Where LINE_MAX should be used and where CONFIG_NSH_LINELEN?
2. Where is LINE_MAX defined?
3. Wouldn't that create inconsistency?
4. This seems to require a documentation update? Or at least mention on the change and what/where is preferred in regard to above two questions?

[xiaoxiang781216]

Thank you @anchao :-) My questions:

1. Where LINE_MAX should be used and where CONFIG_NSH_LINELEN?

Yes, the patch plan to replace all XXX_LINELEN to LINE_MAX.

2. Where is LINE_MAX defined?

here: apache/nuttx#15344
LINE_MAX is POSIX defined macro.

3. Wouldn't that create inconsistency?

no, it improves the consistency, since all places will use the standard macro defined by POSIX.

4. This seems to require a documentation update? Or at least mention on the change and what/where is preferred in regard to above two questions?

[patacongo]

3. Where is LINE_MAX defined?

here: apache/nuttx#15344 LINE_MAX is POSIX defined macro.

Specifically, limits.h: https://pubs.opengroup.org/onlinepubs/7908799/xsh/limits.h.html

Minimum value is _POSIX2_LINE_MAX

[cederom]

3. Where is LINE_MAX defined?

here: apache/nuttx#15344 LINE_MAX is POSIX defined macro.

Specifically, limits.h: https://pubs.opengroup.org/onlinepubs/7908799/xsh/limits.h.html

Minimum value is _POSIX2_LINE_MAX

Yup, and the latest one https://pubs.opengroup.org/onlinepubs/9799919799/ :D

Thank you @patacongo and @xiaoxiang781216 :-)

[cederom]

Thank you @anchao :-)

• Please follow all @xiaoxiang781216 remarks, thank you @xiaoxiang781216 :-)
• Please update commit message apps/system: replace CONFIG_NSH_LINELEN to LINE_MAX so it includes information that this change follows POSIX Specification https://pubs.opengroup.org/onlinepubs/9799919799/.