Buffer overruns in printf
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest0 of 4 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 4 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [U-Boot] [PATCH 0/4] Buffer overruns in printf
Le 24/09/2011 16:00, Simon Glass a ?crit :
Quoted 9 lines
Quoted 9 lines
So basically the choice is between:
- adding code to the
printf()family to try and fix an issue that it is fundamentally unable to properly fix, and for which a solution exists, or- grepping and fixing calls to
*sprintf()in U-Boot that do not respect the known contraints ofprintf(), by resizing the buffer or calling*snprintf()instead.
Quoted 6 lines
Quoted 1 line
I am definitely not in favor of the first option concerning U-Boot.
Sounds fine to me. So I think we need the
nprintf()variants in there, but the message is not to use them willy nilly. Going back to my patch series, 3/4 is ok, but 4/4 mostly crosses the line. Do I have that right?
It is the exact opposite for me : 3/4 makes all printf functions work like some kind of *nprintf(), while 4/4 is about the network code switching to *nprintf() for safety, so 3/4 would be nak and 4/4 ack as far as I am concerned.
Basically, printf family functions which do not have the 'n' are *know* by all -- experienced enough :) -- programmers to be *unsafe* (but to require less from the caller) and it should remain so: no programmer should ever encounter an implementation of printf that pretends to be even somewhat safe, because it might bite him/her elsewhere, in another project based on another C library where printf is just the beartrap it usually is.
IOW, programmers already have assumptions about *printf(), including how to deal with length limitations and what happens if you don't, and it is best that these assumption remain true whatever project they work with.
Quoted 4 lines
By the way,
printf()ends up calling the same code, but without limit checking in place. The alternative is to duplicate all the format string processing code (a limit-checking version and an unchecked version) which would be worse.
I don't intend to dictate the way things can be implemented, so the degree of code reuse is an open question as far as I am concerned. I am only voicing my opinion that *printf() APIs and their contracts should remain identical across all implementations of *printf(), and thus that providing *nprintf() where they don't exist is commandable, but hardening printf() is not, since you basically cannot do it without somewhat departing from the de facto standard.
Quoted 2 lines
Regards,
Simon
Amicalement,
Signature · 1 line
Albert.