The existing minor problem is inconsistency in usage of sprintf/snprintf in firmware (target drivers).
This PR solves it by replacing (almost as-is) the three remaining sprintf calls as highlighted by puncover and grep / the-silver-searcher with snprintf which is used much more often.
Bonus points for bounds checking, as all touched cases deal with copying a runtime-constructed pattern into a target private storage struct, which has a fixed capacity, and it's cheap to take its size [and stuff into second argument] -- not invented by me, I was just looking at other callers of snprintf. There could be stricter bounds enforced, but I won't be researching that.
As measured on gcc-12 and native this drops a 64-byte siprintf shim function from current main, while retaining 104-byte sniprintf with 14 callers and _svfiprintf_r the impl proper. It may be much harder to get rid of that set of efficient newlib-nano library functions, because of e.g. existing XML builders.
I can't test against any of three touched targets.
Detailed description
sprintf
calls as highlighted bypuncover
andgrep
/the-silver-searcher
withsnprintf
which is used much more often.Bonus points for bounds checking, as all touched cases deal with copying a runtime-constructed pattern into a target private storage struct, which has a fixed capacity, and it's cheap to take its size [and stuff into second argument] -- not invented by me, I was just looking at other callers of snprintf. There could be stricter bounds enforced, but I won't be researching that. As measured on gcc-12 and
native
this drops a 64-bytesiprintf
shim function from currentmain
, while retaining 104-bytesniprintf
with 14 callers and_svfiprintf_r
the impl proper. It may be much harder to get rid of that set of efficient newlib-nano library functions, because of e.g. existing XML builders.I can't test against any of three touched targets.
Your checklist for this pull request
Closing issues