Re: [Qemu-trivial] [Qemu-devel] [PATCH] sockets: avoid formatting buffer that may not be NULL terminated

[Thomas Huth]

On 05.07.2017 15:41, Stefan Hajnoczi wrote:
> On Mon, Jun 26, 2017 at 12:19:40PM +0200, Thomas Huth wrote:
>> On 26.06.2017 12:11, Daniel P. Berrange wrote:
>>> The 'sun_path' field in the sockaddr_un struct is not required
>>> to be NULL termianted, so when reporting an error, we must use
>>
>> s/NULL/NUL/
>>
>> NULL is a pointer, NUL is the '\0' character.
> 
> I wanted to point out the same thing to someone recently, so I chased up
> a reference to the NUL character in RFC 20 "ASCII format for Network
> Interchange".  After all, no one can argue with an RFC.
> 
> What I found shocked me!  There must be a typo in the ASCII RFC:
> https://tools.ietf.org/html/rfc20#section-5.2
> 
> I closed my browser tab quickly and headed to Wikipedia instead.  If the
> primary source didn't support my argument, I could always count on good
> old Wikipedia...
> 
> But do you know what I found?  Someone had conflated nul and null on the
> Wikipedia entry:
> https://en.wikipedia.org/wiki/Null_character
> 
> Amateurs!  The Wikipedia editors probably didn't have the intellectual
> calibre to question the correctness of the RFC text the way I did.
> 
> But to cut a long story short, as my search continued the evidence
> became overwhelming.  It is acceptable to refer to the nul character as
> the null character.

Well, I don't see a real problem here - as long as you write "null" with
lowercase letters. "NULL" with uppercase letters is the pointer. "NUL"
with uppercase letters is the character. And "null" with lowercase
letters is just a context-sensitive word :-)

 Thomas

signature.asc
Description: OpenPGP digital signature