diff options
author | Vito Caputo <vcaputo@pengaru.com> | 2019-07-14 17:48:01 -0700 |
---|---|---|
committer | Vito Caputo <vcaputo@pengaru.com> | 2019-07-14 17:48:01 -0700 |
commit | 8f241509d127f114f46c95769c0ec66e51be222b (patch) | |
tree | b4883ce17646b80d53aea648977813824941117f /src/libvmon/defs/_begin.def | |
parent | b6a393bc55476bb65a974e8bd81482287b7f72f3 (diff) |
charts: clamp %n length to buffer size
It appears I overlooked that %n returns the length that would have
been printed regardless of the destination buffer size, not what
was actually written. The man page is misleading here:
n The number of characters written so far is stored into the
integer pointed to by the corresponding argument. That
argument shall be an int *, or variant whose size matches
the (optionally) supplied integer length modifier. No argu‐
ment is converted. (This specifier is not supported by the
bionic C library.) The behavior is undefined if the conver‐
sion specification includes any flags, a field width, or a
precision.
In testing, it isn't the count of what's actually written. It's
oblivious of truncated output scenarios where the output buffer has
been exhausted before reaching the %n. The man page should be
clarified here.
This commit does the simplest thing and simply clamps the length to
the destination buffer - 1 (for the \0). %n is being used to avoid
needing an strlen() in this somewhat hot path, but it might make
sense to instead use the snprintf return value similarly clamped
instead of %n since %n isn't doing what was expected.
Diffstat (limited to 'src/libvmon/defs/_begin.def')
0 files changed, 0 insertions, 0 deletions