From: Dave Korn <dave.korn.cygwin@googlemail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Dave Korn <dave.korn.cygwin@googlemail.com>,
gcc-patches@gcc.gnu.org, gdb-patches@sourceware.org
Subject: Re: [RFA] Fix documentation of snprintf and vsnprintf
Date: Sat, 23 May 2009 20:09:00 -0000 [thread overview]
Message-ID: <4A185A9D.8090500@gmail.com> (raw)
In-Reply-To: <837i07u4k7.fsf@gnu.org>
Eli Zaretskii wrote:
>> Date: Sat, 23 May 2009 15:29:20 +0100
>> From: Dave Korn <dave.korn.cygwin@googlemail.com>
>> CC: gcc@gcc.gnu.org, gcc-patches@gcc.gnu.org
>>
>> I think it's still a little bit unclear:
>>
>>> +This function is similar to @code{sprintf}, but it will write at most
>>> +var{n} bytes (including the terminating null byte) to @var{buf}.
>> It could still be perceived as ambiguous. That sentence says that the
>> terminating null byte is included in the count of
>> "the-most-bytes-it-will-write", but it doesn't explicitly say that it won't be
>> truncated off like the rest of the characters if the output is too long.
>
> I thought it did say that, as
>
> "write at most N bytes (including the terminating null byte)"
>
> means that it will write no more than N bytes, and those N bytes
> include the null byte.
Yes, the text can be taken to mean this as well, and that is clearly the
intended meaning once you know, but it's about how this sentence says the NUL
terminating byte should be *counted* the same as all the rest, it might seem
to imply that it is *treated* the same as all the rest - and it's not, it's
treated differently.
> However, I don't mind the text you suggest if people think it says the
> same more clearly:
>
>> How about
>>
>>> +This function is similar to @code{sprintf}, but it will write at most
>>> +var{n} bytes (truncating the output if necessary, so that there is
>>> +always guaranteed to be a terminating null byte) to @var{buf}.
>
> Or maybe we should make it clearer still:
>
> This function is similar to @code{sprintf}, but it will write to
> @var{buf} at most @code{var{n}-1} bytes of text, followed by a
> terminating null byte, for the total of @var{n} bytes.
>
> WDYT?
That WFM just fine too :)
cheers,
DaveK
next prev parent reply other threads:[~2009-05-23 20:09 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <83d4a0szry.fsf@gnu.org>
[not found] ` <4A180840.3040004@gmail.com>
2009-05-23 17:13 ` Eli Zaretskii
2009-05-23 20:09 ` Dave Korn [this message]
2009-05-23 13:48 Eli Zaretskii
2009-05-23 13:55 ` Pedro Alves
2009-05-23 17:02 ` Eli Zaretskii
2009-05-29 11:43 ` Eli Zaretskii
2009-05-29 20:22 ` DJ Delorie
2009-05-29 20:28 ` Dave Korn
2009-05-29 20:34 ` DJ Delorie
2009-05-29 20:39 ` Dave Korn
2009-05-29 20:59 ` Eli Zaretskii
2009-05-29 20:42 ` Eli Zaretskii
2009-05-29 20:45 ` DJ Delorie
2009-05-29 21:44 ` Eli Zaretskii
2009-05-30 5:18 ` DJ Delorie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A185A9D.8090500@gmail.com \
--to=dave.korn.cygwin@googlemail.com \
--cc=eliz@gnu.org \
--cc=gcc-patches@gcc.gnu.org \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox