Re: [Qemu-devel] [PATCH 2/2] qemu-img: fix some spelling errors

From: 858585 jemmy <jemmy858585@gmail.com>
To: Max Reitz <mreitz@redhat.com>
Cc: "Eric Blake" <eblake@redhat.com>,
	"Philippe Mathieu-Daudé" <f4bug@amsat.org>,
	"Lidong Chen" <lidongchen@tencent.com>,
	"Kevin Wolf" <kwolf@redhat.com>,
	qemu-devel <qemu-devel@nongnu.org>,
	"qemu block" <qemu-block@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH 2/2] qemu-img: fix some spelling errors
Date: Wed, 26 Apr 2017 16:05:16 +0800	[thread overview]
Message-ID: <CAOGPPbcza7BcVhiFoY9rj7QBS2n=573CxHhXYe4U6RSMNOdO7Q@mail.gmail.com> (raw)
In-Reply-To: <4d38eb43-f61d-106a-ffd4-d4f0c76df71d@redhat.com>

On Wed, Apr 26, 2017 at 3:11 AM, Max Reitz <mreitz@redhat.com> wrote:
> On 24.04.2017 17:53, Eric Blake wrote:
>> On 04/24/2017 10:47 AM, Eric Blake wrote:
>>> On 04/24/2017 10:37 AM, Philippe Mathieu-Daudé wrote:
>>>
>>>>>>  /*
>>>>>> - * Returns true iff the first sector pointed to by 'buf' contains at
>>>>>> least
>>>>>> - * a non-NUL byte.
>>>>>> + * Returns true if the first sector pointed to by 'buf' contains at
>>>>>> least
>>>>>> + * a non-NULL byte.
>>>>>
>>>>> NACK to both changes.  'iff' is an English word that is shorthand for
>>>>> "if and only if".  "NUL" means the one-byte character, while "NULL"
>>>>> means the 8-byte (or 4-byte, on 32-bit platform) pointer value.
>>>>
>>>> I agree with Lidong shorthands are not obvious from non-native speaker.
>>>>
>>>> What about this?
>>>>
>>>>  * Returns true if (and only if) the first sector pointed to by 'buf'
>>>> contains
>>>
>>> That might be okay.
>
> Might, yes, but we have it all over the code. I'm not particularly avid
> to change this, because I am in fact one of the culprits (and I'm a
> non-native speaker, but I do like to use LaTeX so I know my \iff).
>
> (By the way, judging from the author's name of this line of code (which
> is Thiemo Seufer), I'd wager he's not a native speaker either.)
>
>>>>  * at least a non-null character.
>>>
>>> But that still doesn't make sense.  The character name is NUL, and
>>> non-NULL refers to something that is a pointer, not a character.
>>
>> What's more, the NUL character can actually occupy more than one byte
>> (think UTF-16, where it is the two-byte 0 value).  Referring to NUL byte
>> rather than NUL character (or even the 'zero byte') makes it obvious
>> that this function is NOT encoding-sensitive, and doesn't start
>> mis-behaving just because the data picks a multi-byte character encoding.
>
> Furthermore, this doesn't have anything to do with being a native
> speaker or not: NUL is just the commonly used and probably standardized
> abbreviation of a certain ASCII character (in any language). It's OK not
> to know this, but I don't think it's OK to change the comment.
Thanks for your explanation.
>
> Max
>