Bug 180767 - [patch] printf.3: fix off-by-one in snprintf description
Summary: [patch] printf.3: fix off-by-one in snprintf description
Status: In Progress
Alias: None
Product: Documentation
Classification: Unclassified
Component: Manual Pages (show other bugs)
Version: Latest
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-bugs (Nobody)
URL:
Keywords: patch
Depends on:
Blocks:
 
Reported: 2013-07-23 16:10 UTC by Dmitry Marakasov
Modified: 2018-08-05 06:46 UTC (History)
5 users (show)

See Also:


Attachments
printf.3.patch (423 bytes, patch)
2013-07-23 16:10 UTC, Dmitry Marakasov
no flags Details | Diff
new patch (432 bytes, patch)
2014-08-27 22:00 UTC, Dmitry Marakasov
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Dmitry Marakasov freebsd_committer 2013-07-23 16:10:00 UTC
printf(3) says for snprintf:

     The snprintf() and vsnprintf() functions will write at most size-1 of the
     characters printed into the output string (the size'th character then
     gets the terminating `\0');

the part in parenteses is incorrect: size'th character is outside
buffer of [size] characters. It should instead say "(size-1)'th
character" (which is last in the buffer).
Comment 1 Ben Kaduk 2013-07-23 22:07:02 UTC
On Tue, 23 Jul 2013, Dmitry Marakasov wrote:

>
>
>> Description:
> printf(3) says for snprintf:
>
>     The snprintf() and vsnprintf() functions will write at most size-1 of the
>     characters printed into the output string (the size'th character then
>     gets the terminating `\0');
>
> the part in parenteses is incorrect: size'th character is outside
> buffer of [size] characters. It should instead say "(size-1)'th
> character" (which is last in the buffer).

I think one could argue either way.  The character with index (size-1) 
gets the NUL byte, but if one says that the first character is the one 
with index 0, then it is in fact the size'th character which receives the 
NUL.

-Ben Kaduk
Comment 2 Dmitry Marakasov freebsd_committer 2014-08-27 22:00:05 UTC
Created attachment 146411 [details]
new patch

New patch which resolves the ambiguity
Comment 3 Ed Maste freebsd_committer 2018-01-29 21:50:39 UTC
I agree with Ben that it could be argued either way. However, the description should be unambiguous, so that ambiguity exists is an argument for a change.