| Message ID | 1348772258-31168-1-git-send-email-sw@weilnetz.de |
|---|---|
| State | Accepted |
| Headers | show |
On 27 September 2012 19:57, Stefan Weil <sw@weilnetz.de> 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? I would tend to agree, but I have a feeling this insure/ensure distinction is more strongly held in British English than US English... > /* > * Lower bounds on packet lengths for various types. > - * 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. > -- ...however I think the more serious issue with this sentence is not the spelling but that I really have very little idea what it is trying to say. Is it "[error advice] packets" or "error [advice packets]", or "For the error, [advice packets]" or "For the [error advice], packets" ? And a packet can't ensure anything anyway, so who is actually ensuring this (and what happens if they don't do it)? -- PMM
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. >
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
On Thu, Sep 27, 2012 at 08:57:38PM +0200, 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? > > Thanks, > > Stefan > > slirp/ip_icmp.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Thanks, applied to the trivial patches tree: https://github.com/stefanha/qemu/commits/trivial-patches Stefan
diff --git a/slirp/ip_icmp.h b/slirp/ip_icmp.h index 1a1af91..be4426b 100644 --- a/slirp/ip_icmp.h +++ b/slirp/ip_icmp.h @@ -92,8 +92,8 @@ struct icmp { /* * Lower bounds on packet lengths for various types. - * 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.
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? Thanks, Stefan slirp/ip_icmp.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)