anchao commented on issue #21467:
URL: https://github.com/apache/nuttx/issues/21467#issuecomment-6649259379
@casaroli
Thanks for the clarification — and I agree with "if printf is used
correctly, it never crashes." My point is more about where the boundary should
be drawn and how we decide what's worth fixing.
Several of the cases you cite (e.g. a %300d overrun, a width/argument
mismatch, a wrong type for a given conversion) are really programmer errors —
the format string and the arguments don't agree. In a language like Rust this
class of bug is caught at compile time, not at runtime:
```
println!("{:?}|{}", 1.0, "x"); // OK
println!("{:x}|{}", 1.0, "x"); // error: `{x}` (LowerHex) is not
implemented for `{float}`
println!("{}|{}", 1.0); // error: 2 positional arguments in
format string, but there is 1 argument
println!("{}", 1.0, "x"); // error: argument never used
```
C pushed a lot of this memory burden onto the developer by design. It's no
coincidence that GCC/Clang have been steadily adding compile-time checks for
common libc functions over the past few releases — they're slowly catching up
because they can solve these at the language level. The legacy constraints are
exactly why they're moving cautiously.
My view is this: if these problems are eventually going to be solved by the
compiler, then we probably shouldn't spend firmware flash budget defending
against code that only an inexperienced developer would write anyway — and that
AI, if anything, writes even less of.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
