Unicode: ugh!

[Ben Pfaff]

The Unicode standard says this in section 3.9:

"For example, a string is defined as a pointer to char in the
C language, and is conventionally terminated with a NULL
character."

You'd think folks writing standards would bother to properly read
and understand the other standards that they reference.
--
"There's only one thing that will make them stop hating you.
And that's being so good at what you do that they can't ignore you.
I told them you were the best. Now you damn well better be."
--Orson Scott Card, _Ender's Game_

[Artie Gold]

Ben Pfaff wrote:

The Unicode standard says this in section 3.9:

"For example, a string is defined as a pointer to char in the
C language, and is conventionally terminated with a NULL
character."

You'd think folks writing standards would bother to properly read
and understand the other standards that they reference.

....and your C question is...

;-) ;-)

--ag

--
Artie Gold -- Austin, Texas
http://goldsays.blogspot.com
"You can't KISS* unless you MISS**"
[*-Keep it simple, stupid. **-Make it simple, stupid.]

[osmium]

"Ben Pfaff" writes:

The Unicode standard says this in section 3.9:

"For example, a string is defined as a pointer to char in the
C language, and is conventionally terminated with a NULL
character."

You'd think folks writing standards would bother to properly read
and understand the other standards that they reference.

What's your complaint? That the ASCII null should be spelled NUL?

[Ben Pfaff]

"osmium" <r1********@comcast.net> writes:

"Ben Pfaff" writes:

The Unicode standard says this in section 3.9:

"For example, a string is defined as a pointer to char in the
C language, and is conventionally terminated with a NULL
character."

You'd think folks writing standards would bother to properly read
and understand the other standards that they reference.

What's your complaint? That the ASCII null should be spelled NUL?

Here is the definition of a string:

A string is a contiguous sequence of characters terminated
by and including the first null character.

A string is not a pointer to char: it is a sequence of
characters. It is not "conventionally" terminated by a null
character, it is always terminated by one (otherwise it is not a
string). In C, the null terminator is not a NULL character (NULL
is a null pointer constant); it is not the NUL character either,
because that assumes an ASCII character set; the null terminator
is in fact the "null character", as quoted above.

It's amazing how much they managed to get wrong in a single
sentence.
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[osmium]

"Ben Pfaff" wrote:

"osmium" <r1********@comcast.net> writes:

"Ben Pfaff" writes:

The Unicode standard says this in section 3.9:

"For example, a string is defined as a pointer to char in the
C language, and is conventionally terminated with a NULL
character."

You'd think folks writing standards would bother to properly read
and understand the other standards that they reference.
What's your complaint? That the ASCII null should be spelled NUL?

Here is the definition of a string:

A string is a contiguous sequence of characters terminated
by and including the first null character.

A string is not a pointer to char: it is a sequence of
characters. It is not "conventionally" terminated by a null
character, it is always terminated by one (otherwise it is not a
string). In C, the null terminator is not a NULL character (NULL
is a null pointer constant); it is not the NUL character either,
because that assumes an ASCII character set; the null terminator
is in fact the "null character", as quoted above.

I glossed over the word "conventionally", that is not a good basis for a
definition. As far as the ASCII component, I figured that was justified
somewhere in the thicket of documents. Every UTF I have seen embeds ASCII
in it. But I don't claim to have seen all the UTF's that exist.
It's amazing how much they managed to get wrong in a single
sentence.

I just read it again and I now agree with you. I thought earlier you were
nit-picking on the extra 'L'.

[Keith Thompson]

"osmium" <r1********@comcast.net> writes:

"Ben Pfaff" wrote:

"osmium" <r1********@comcast.net> writes:

"Ben Pfaff" writes:
The Unicode standard says this in section 3.9:

"For example, a string is defined as a pointer to char in the
C language, and is conventionally terminated with a NULL
character."

You'd think folks writing standards would bother to properly read
and understand the other standards that they reference.

What's your complaint? That the ASCII null should be spelled NUL?

Here is the definition of a string:

A string is a contiguous sequence of characters terminated
by and including the first null character.

A string is not a pointer to char: it is a sequence of
characters. It is not "conventionally" terminated by a null
character, it is always terminated by one (otherwise it is not a
string). In C, the null terminator is not a NULL character (NULL
is a null pointer constant); it is not the NUL character either,
because that assumes an ASCII character set; the null terminator
is in fact the "null character", as quoted above.

I glossed over the word "conventionally", that is not a good basis for a
definition. As far as the ASCII component, I figured that was justified
somewhere in the thicket of documents. Every UTF I have seen embeds ASCII
in it. But I don't claim to have seen all the UTF's that exist.

It's amazing how much they managed to get wrong in a single
sentence.

I just read it again and I now agree with you. I thought earlier you were
nit-picking on the extra 'L'.

Even if that were the only problem, it would be enough of a basis to
criticize it. NULL has a very well-defined meaning in C, and it has
very little to do with the '\0' character.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Richard G. Riley]

On 2006-03-13, Keith Thompson <ks***@mib.org> wrote:

Even if that were the only problem, it would be enough of a basis to
criticize it. NULL has a very well-defined meaning in C, and it has
very little to do with the '\0' character.

In restrospect it was a bit silly to have a NULL and a "null"
character,'\0', and then to compound it all with a "null pointer"... 2
seconds with google shows generations of confusion and standards
abuse.

[Jordan Abel]

On 2006-03-13, Keith Thompson <ks***@mib.org> wrote:

"osmium" <r1********@comcast.net> writes:

"Ben Pfaff" wrote:

"osmium" <r1********@comcast.net> writes:
"Ben Pfaff" writes:
> The Unicode standard says this in section 3.9:
>
> "For example, a string is defined as a pointer to char in the
> C language, and is conventionally terminated with a NULL
> character."
>
> You'd think folks writing standards would bother to properly read
> and understand the other standards that they reference.

What's your complaint? That the ASCII null should be spelled NUL?

Here is the definition of a string:

A string is a contiguous sequence of characters terminated
by and including the first null character.

A string is not a pointer to char: it is a sequence of
characters. It is not "conventionally" terminated by a null
character, it is always terminated by one (otherwise it is not a
string). In C, the null terminator is not a NULL character (NULL
is a null pointer constant); it is not the NUL character either,
because that assumes an ASCII character set; the null terminator
is in fact the "null character", as quoted above.

I glossed over the word "conventionally", that is not a good basis for a
definition. As far as the ASCII component, I figured that was justified
somewhere in the thicket of documents. Every UTF I have seen embeds ASCII
in it. But I don't claim to have seen all the UTF's that exist.

It's amazing how much they managed to get wrong in a single
sentence.

I just read it again and I now agree with you. I thought earlier you were
nit-picking on the extra 'L'.

Even if that were the only problem, it would be enough of a basis to
criticize it. NULL has a very well-defined meaning in C, and it has
very little to do with the '\0' character.

Though, '\0' is incidentally a null pointer constant... so #define NULL
'\0' would be legal.

[Keith Thompson]

Jordan Abel <ra*******@gmail.com> writes:

On 2006-03-13, Keith Thompson <ks***@mib.org> wrote:

[...]

Even if that were the only problem, it would be enough of a basis to
criticize it. NULL has a very well-defined meaning in C, and it has
very little to do with the '\0' character.

Though, '\0' is incidentally a null pointer constant... so #define NULL
'\0' would be legal.

Yes, of course; that's the "very little" I was referring to.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Richard Tobin]

In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.org> wrote:

Even if that were the only problem, it would be enough of a basis to
criticize it. NULL has a very well-defined meaning in C, and it has
very little to do with the '\0' character.

However, the text is in the Unicode standard, and there NULL means the
character with code 0.

-- Richard

[lawrence.jones]

Ben Pfaff <bl*@cs.stanford.edu> wrote:

You'd think folks writing standards would bother to properly read
and understand the other standards that they reference.

Not after you've worked in the standards world for a while, you
wouldn't. :-) Of course, some committees are better than others.

-Larry Jones

Wow, how existential can you get? -- Hobbes

[Richard Bos]

Ben Pfaff <bl*@cs.stanford.edu> wrote:

The Unicode standard says this in section 3.9:

"For example, a string is defined as a pointer to char in the
C language, and is conventionally terminated with a NULL
character."

You'd think folks writing standards would bother to properly read
and understand the other standards that they reference.

The Unicode Standard (at least, the PDFs I have) also says this in its
first character chart (chapter 16, I believe):

"0000 [NUL] <control>
= NULL"

So _within the bounds of Unicode_ that comment is correct. The Unicode
name for character 0, ASCII NUL, the null character, is (and has been
for a while, don't know how long) NULL. This choice was ill-advised,
yes, but it having been made, your quotation is wrong in a general C
context, but correct in a Unicode context.

Richard

[Ben Pfaff]

rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:

Ben Pfaff <bl*@cs.stanford.edu> wrote:

The Unicode standard says this in section 3.9:

"For example, a string is defined as a pointer to char in the
C language, and is conventionally terminated with a NULL
character."

You'd think folks writing standards would bother to properly read
and understand the other standards that they reference.

[NULL is correct for Unicode.]

There's a lot more wrong with it than misspelling "null".
--
"The way I see it, an intelligent person who disagrees with me is
probably the most important person I'll interact with on any given
day."
--Billy Chambless

[Jordan Abel]

On 2006-03-14, Richard Bos <rl*@hoekstra-uitgeverij.nl> wrote:

Ben Pfaff <bl*@cs.stanford.edu> wrote:

The Unicode standard says this in section 3.9:

"For example, a string is defined as a pointer to char in the
C language, and is conventionally terminated with a NULL
character."

You'd think folks writing standards would bother to properly read
and understand the other standards that they reference.

The Unicode Standard (at least, the PDFs I have) also says this in its
first character chart (chapter 16, I believe):

"0000 [NUL] <control>
= NULL"

So _within the bounds of Unicode_ that comment is correct. The Unicode
name for character 0, ASCII NUL, the null character, is (and has been
for a while, don't know how long) NULL. This choice was ill-advised,
yes, but it having been made, your quotation is wrong in a general C
context, but correct in a Unicode context.

Well, yeah. That's the english word/phrase for which NUL is an
abbreviation, just like we have START OF TEXT for STX, and so on.

[Dik T. Winter]

In article <44****************@news.xs4all.nl> rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:
....

The Unicode
name for character 0, ASCII NUL, the null character, is (and has been
for a while, don't know how long) NULL.

That name was already present in Unicode 1.1.5 (July 1995) (the earliest
reference that is available online).
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, [phone]
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

[Ben Pfaff]

rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:

Ben Pfaff <bl*@cs.stanford.edu> wrote:

The Unicode standard says this in section 3.9:

"For example, a string is defined as a pointer to char in the
C language, and is conventionally terminated with a NULL
character."

You'd think folks writing standards would bother to properly read
and understand the other standards that they reference.

The Unicode Standard (at least, the PDFs I have) also says this in its
first character chart (chapter 16, I believe):

"0000 [NUL] <control>
= NULL"

So _within the bounds of Unicode_ that comment is correct. The Unicode
name for character 0, ASCII NUL, the null character, is (and has been
for a while, don't know how long) NULL. This choice was ill-advised,
yes, but it having been made, your quotation is wrong in a general C
context, but correct in a Unicode context.

I took another look at the text I quoted. At a second look, it
is clearly *not* referring to the Unicode character called NULL,
because Unicode character names in the Unicode standard are
expressed in small capital letters. The NULL in the paragraph
above is in full-size capital letters, so it does not refer to a
Unicode character name.
--
"I don't have C&V for that handy, but I've got Dan Pop."
--E. Gibbons

[Richard Tobin]

In article <87************@benpfaff.org>,
Ben Pfaff <bl*@cs.stanford.edu> wrote:

I took another look at the text I quoted. At a second look, it
is clearly *not* referring to the Unicode character called NULL,
because Unicode character names in the Unicode standard are
expressed in small capital letters.

They are in small caps when written as (for example) "U+004B LATIN
CAPITAL LETTER K", but they also appear (without the U+XXXX) in plain
capitals (e.g. in the character tables themselves), lower case, and
italics. So I don't think you can deduce that they are not referring
to the Unicode character. Though they might well be using it in a
more generic sense of a null character without reference to Unicode in
particular (which would be more accurate in a sense, because as far as
I can see nothing guarantees that C's string-terminating character
maps to U+0000).

Anyway, I certainly don't think you can assume the author was
confusing it with the C macro NULL.

-- Richard

[Richard Bos]

ri*****@cogsci.ed.ac.uk (Richard Tobin) wrote:

In article <87************@benpfaff.org>,
Ben Pfaff <bl*@cs.stanford.edu> wrote:

I took another look at the text I quoted. At a second look, it
is clearly *not* referring to the Unicode character called NULL,
because Unicode character names in the Unicode standard are
expressed in small capital letters.

They are in small caps when written as (for example) "U+004B LATIN
CAPITAL LETTER K", but they also appear (without the U+XXXX) in plain
capitals (e.g. in the character tables themselves), lower case, and
italics. So I don't think you can deduce that they are not referring
to the Unicode character. Though they might well be using it in a
more generic sense of a null character without reference to Unicode in
particular (which would be more accurate in a sense, because as far as
I can see nothing guarantees that C's string-terminating character
maps to U+0000).

The null character in C must be a character with value zero. U+0000
trivially also has value zero. If an implementation manages not to map
the one onto the other, I would say that that implementation does not
have Unicode as its character set, but at most Unicode-rearranged.

Richard