From: Stefan Weil <sw@weilnetz.de>
To: Eric Blake <eblake@redhat.com>
Cc: qemu-trivial@nongnu.org, Jan Kiszka <jan.kiszka@siemens.com>,
qemu-devel@nongnu.org, Peter Maydell <peter.maydell@linaro.org>
Subject: Re: [Qemu-trivial] [Qemu-devel] [PATCH] slirp: Fix spelling in comment (enought -> enough, insure -> ensure)
Date: Thu, 27 Sep 2012 22:49:48 +0200 [thread overview]
Message-ID: <5064BBEC.8000007@weilnetz.de> (raw)
In-Reply-To: <5064A546.9080302@redhat.com>
Am 27.09.2012 21:13, schrieb Eric Blake:
> On 09/27/2012 12:57 PM, Stefan Weil wrote:
>> Signed-off-by: Stefan Weil<sw@weilnetz.de>
>> ---
>>
>> As a non native speaker, I feel that 'ensure' is better here than 'insure'.
>> Could a native speaker please confirm that?
>
> As a US speaker, I've seen both words used interchangeably. I also
> checked dictionary.com, where both words imply a guarantee, but 'insure'
> has a connotation of a guarantee against loss (think insurance policy)
> while 'ensure' tends to be used in most other situations. That is, I am
> in favor of this spelling change for connotation reasons. But as Peter
> pointed out, the sentence has more problems than just a spelling choice.
>
>> - * For the error advice packets must first insure that the
>> - * packet is large enought to contain the returned ip header.
>> + * For the error advice packets must first ensure that the
>> + * packet is large enough to contain the returned ip header.
>> * Only then can we do the check to see if 64 bits of packet
>> * data have been returned, since we need to check the returned
>> * ip header length.
Thanks for your and Peter's annotations.
It looks like these lines of comment are much older than QEMU.
I found code from 1995 which already contains them.
They are spread in BSD, Apple and Microsoft code,
so maybe we should add a comment which marks them
as a historic artefact which must be preserved :-)
I might also try to improve that sentence by adding 'we':
+ * For the error advice packets we must first ensure that the
+ * packet is large enough to contain the returned ip header.
or
+ * For the error advice packets we must first ensure that
+ * they are large enough to contain the returned ip header.
ICMP_ADVLENMIN seems to be the minimum length which meaningful
'error advice packets' must have.
Regards
Stefan
WARNING: multiple messages have this Message-ID (diff)
From: Stefan Weil <sw@weilnetz.de>
To: Eric Blake <eblake@redhat.com>
Cc: qemu-trivial@nongnu.org, Jan Kiszka <jan.kiszka@siemens.com>,
qemu-devel@nongnu.org, Peter Maydell <peter.maydell@linaro.org>
Subject: Re: [Qemu-devel] [PATCH] slirp: Fix spelling in comment (enought -> enough, insure -> ensure)
Date: Thu, 27 Sep 2012 22:49:48 +0200 [thread overview]
Message-ID: <5064BBEC.8000007@weilnetz.de> (raw)
In-Reply-To: <5064A546.9080302@redhat.com>
Am 27.09.2012 21:13, schrieb Eric Blake:
> On 09/27/2012 12:57 PM, Stefan Weil wrote:
>> Signed-off-by: Stefan Weil<sw@weilnetz.de>
>> ---
>>
>> As a non native speaker, I feel that 'ensure' is better here than 'insure'.
>> Could a native speaker please confirm that?
>
> As a US speaker, I've seen both words used interchangeably. I also
> checked dictionary.com, where both words imply a guarantee, but 'insure'
> has a connotation of a guarantee against loss (think insurance policy)
> while 'ensure' tends to be used in most other situations. That is, I am
> in favor of this spelling change for connotation reasons. But as Peter
> pointed out, the sentence has more problems than just a spelling choice.
>
>> - * For the error advice packets must first insure that the
>> - * packet is large enought to contain the returned ip header.
>> + * For the error advice packets must first ensure that the
>> + * packet is large enough to contain the returned ip header.
>> * Only then can we do the check to see if 64 bits of packet
>> * data have been returned, since we need to check the returned
>> * ip header length.
Thanks for your and Peter's annotations.
It looks like these lines of comment are much older than QEMU.
I found code from 1995 which already contains them.
They are spread in BSD, Apple and Microsoft code,
so maybe we should add a comment which marks them
as a historic artefact which must be preserved :-)
I might also try to improve that sentence by adding 'we':
+ * For the error advice packets we must first ensure that the
+ * packet is large enough to contain the returned ip header.
or
+ * For the error advice packets we must first ensure that
+ * they are large enough to contain the returned ip header.
ICMP_ADVLENMIN seems to be the minimum length which meaningful
'error advice packets' must have.
Regards
Stefan
next prev parent reply other threads:[~2012-09-27 20:49 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-27 18:57 [Qemu-trivial] [PATCH] slirp: Fix spelling in comment (enought -> enough, insure -> ensure) Stefan Weil
2012-09-27 18:57 ` [Qemu-devel] " Stefan Weil
2012-09-27 19:07 ` [Qemu-trivial] " Peter Maydell
2012-09-27 19:07 ` Peter Maydell
2012-09-27 19:13 ` [Qemu-trivial] " Eric Blake
2012-09-27 19:13 ` Eric Blake
2012-09-27 20:49 ` Stefan Weil [this message]
2012-09-27 20:49 ` Stefan Weil
2012-10-05 12:25 ` [Qemu-trivial] " Stefan Hajnoczi
2012-10-05 12:25 ` Stefan Hajnoczi
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=5064BBEC.8000007@weilnetz.de \
--to=sw@weilnetz.de \
--cc=eblake@redhat.com \
--cc=jan.kiszka@siemens.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-trivial@nongnu.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.