Rainer Weikusat <rweikusat@talktalk.net> writes:
> Richard Kettlewell <invalid@invalid.invalid> writes:
>> “char” isn’t just a random string of symbols. It’s obvious both from the
>> name and the way it’s used in the language that it’s intended to
>> represent characters, not just small integer values.
>
> Computers have absolutely no idea of "characters". They handle numbers,
> integer numbers in this case, and humans then interpret them as
> characters based on some convention for encoding characters as
> integers. Hence, a data type suitable for holding an encoded character
> (ie, an integer value from 0 - 127 for the case in question) is not the
> same as a character.

Language designers do, however, have an idea of “characters”.

--
https://www.greenend.org.uk/rjk/

On Wed, 07 Feb 2024 20:20:12 +0000, Richard Kettlewell wrote:

> Language designers do, however, have an idea of “characters”.

Unicode uses the terms “grapheme” and “text element”. Actually it also
uses “character”, but it seems less clear on what that means. It is not
the same as a “code point” or “glyph”.

<https://www.unicode.org/faq/char_combmark.html>

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

> On Wed, 07 Feb 2024 20:20:12 +0000, Richard Kettlewell wrote:
>
>> Language designers do, however, have an idea of “characters”.
>
> Unicode uses the terms “grapheme” and “text element”. Actually it also
> uses “character”, but it seems less clear on what that means. It is not
> the same as a “code point” or “glyph”.
>
> <https://www.unicode.org/faq/char_combmark.html>

Sure, but this was all happening in the 1970s, long before Unicode
existed.

K&R1 explicitly says char is “capable of holding one character in the
local character set” (and mentions EBCDIC as a concrete example on the
same page - the problem must have been obvious already).

--
https://www.greenend.org.uk/rjk/

Richard Kettlewell <invalid@invalid.invalid> writes:
> Rainer Weikusat <rweikusat@talktalk.net> writes:
>> Richard Kettlewell <invalid@invalid.invalid> writes:
>>> “char” isn’t just a random string of symbols. It’s obvious both from the
>>> name and the way it’s used in the language that it’s intended to
>>> represent characters, not just small integer values.
>>
>> Computers have absolutely no idea of "characters". They handle numbers,
>> integer numbers in this case, and humans then interpret them as
>> characters based on some convention for encoding characters as
>> integers. Hence, a data type suitable for holding an encoded character
>> (ie, an integer value from 0 - 127 for the case in question) is not the
>> same as a character.
>
> Language designers do, however, have an idea of “characters”.

I don't quite understand what that's supposed to communicate. Insofar
the machine is concerned, a character is nothig but an integer and a
data type sufficient to hold a characters is thus necessarily an integer
type of some size. In a language without unsigned integer types, it'll
necessarily also be an signed integer type.

Rainer Weikusat <rweikusat@talktalk.net> writes:
> Richard Kettlewell <invalid@invalid.invalid> writes:
>> Rainer Weikusat <rweikusat@talktalk.net> writes:
>>> Richard Kettlewell <invalid@invalid.invalid> writes:
>>>> “char” isn’t just a random string of symbols. It’s obvious both from the
>>>> name and the way it’s used in the language that it’s intended to
>>>> represent characters, not just small integer values.
>>>
>>> Computers have absolutely no idea of "characters". They handle numbers,
>>> integer numbers in this case, and humans then interpret them as
>>> characters based on some convention for encoding characters as
>>> integers. Hence, a data type suitable for holding an encoded character
>>> (ie, an integer value from 0 - 127 for the case in question) is not the
>>> same as a character.
>>
>> Language designers do, however, have an idea of “characters”.
>
> I don't quite understand what that's supposed to communicate. Insofar
> the machine is concerned, a character is nothig but an integer and a
> data type sufficient to hold a characters is thus necessarily an integer
> type of some size. In a language without unsigned integer types, it'll
> necessarily also be an signed integer type.

Early C (pre-K&R1) didn't explicitly have unsigned integer types, but
char was effectively unsigned in some implementations, in that
converting a char value to int would zero-fill the result rather than
doing sign-extension.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> Rainer Weikusat <rweikusat@talktalk.net> writes:
>> Richard Kettlewell <invalid@invalid.invalid> writes:
>>> Rainer Weikusat <rweikusat@talktalk.net> writes:
>>>> Richard Kettlewell <invalid@invalid.invalid> writes:
>>>>> “char” isn’t just a random string of symbols. It’s obvious both from the
>>>>> name and the way it’s used in the language that it’s intended to
>>>>> represent characters, not just small integer values.
>>>>
>>>> Computers have absolutely no idea of "characters". They handle numbers,
>>>> integer numbers in this case, and humans then interpret them as
>>>> characters based on some convention for encoding characters as
>>>> integers. Hence, a data type suitable for holding an encoded character
>>>> (ie, an integer value from 0 - 127 for the case in question) is not the
>>>> same as a character.
>>>
>>> Language designers do, however, have an idea of “characters”.
>>
>> I don't quite understand what that's supposed to communicate. Insofar
>> the machine is concerned, a character is nothig but an integer and a
>> data type sufficient to hold a characters is thus necessarily an integer
>> type of some size. In a language without unsigned integer types, it'll
>> necessarily also be an signed integer type.
>
> Early C (pre-K&R1) didn't explicitly have unsigned integer types, but
> char was effectively unsigned in some implementations, in that
> converting a char value to int would zero-fill the result rather than
> doing sign-extension.

According to Ritchie's "The Development of the C Language"

,----
| During 1973-1980, the language grew a bit: the type structure gained
| unsigned
|
| [...]
|
| the similarity of the arithmetic properties of character pointers and
| unsigned integers made it hard to resist the temptation to identify
| them. The unsigned types were added to make unsigned arithmetic
| available without confusing it with pointer manipulation. Similarly, the
| early language condoned assignments between integers and pointers
`----

Rainer Weikusat <rweikusat@talktalk.net> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Rainer Weikusat <rweikusat@talktalk.net> writes:
>>> Richard Kettlewell <invalid@invalid.invalid> writes:
>>>> Rainer Weikusat <rweikusat@talktalk.net> writes:
>>>>> Richard Kettlewell <invalid@invalid.invalid> writes:
>>>>>> “char” isn’t just a random string of symbols. It’s obvious both from the
>>>>>> name and the way it’s used in the language that it’s intended to
>>>>>> represent characters, not just small integer values.
>>>>>
>>>>> Computers have absolutely no idea of "characters". They handle numbers,
>>>>> integer numbers in this case, and humans then interpret them as
>>>>> characters based on some convention for encoding characters as
>>>>> integers. Hence, a data type suitable for holding an encoded character
>>>>> (ie, an integer value from 0 - 127 for the case in question) is not the
>>>>> same as a character.
>>>>
>>>> Language designers do, however, have an idea of “characters”.
>>>
>>> I don't quite understand what that's supposed to communicate. Insofar
>>> the machine is concerned, a character is nothig but an integer and a
>>> data type sufficient to hold a characters is thus necessarily an integer
>>> type of some size. In a language without unsigned integer types, it'll
>>> necessarily also be an signed integer type.
>>
>> Early C (pre-K&R1) didn't explicitly have unsigned integer types, but
>> char was effectively unsigned in some implementations, in that
>> converting a char value to int would zero-fill the result rather than
>> doing sign-extension.
>
> According to Ritchie's "The Development of the C Language"
>
> ,----
> | During 1973-1980, the language grew a bit: the type structure gained
> | unsigned
> |
> | [...]
> |
> | the similarity of the arithmetic properties of character pointers and
> | unsigned integers made it hard to resist the temptation to identify
> | them. The unsigned types were added to make unsigned arithmetic
> | available without confusing it with pointer manipulation. Similarly, the
> | early language condoned assignments between integers and pointers
> `----

Right. K&R1 (1978) had "unsigned", but only for unsigned int. Still,
the signedness of char was effectively implementation-defined, though it
wasn't stated in those terms.

From K&R1:

A character or a short integer may be used wherever an
integer may be used. In all cases the value is converted to
an integer. Conversion of a shorter integer to a longer always
involves sign extension; integers are signed quantities. Whether
or not sign-extension occurs for characters is machine dependent,
but it is guaranteed that a member of the standard character
set is non-negative. Of the machines treated by this manual,
only the PDP-11 sign-extends. On the PDP-11, character variables
range in value from -128 to 127; the characters of the ASCII
alphabet are all positive. A character constant specified with
an octal escape suffers sign extension and may appear negative;
for example, '\377' has the value -1.

The sentence "Whether or not sign-extension occurs for characters is
machine dependent" might be written in more modern terms as "The
signedness of char is implementation-defined".

signed char and unsigned char (and unsigned short and unsigned long)
were added in ANSI C 1989, possibly earlier.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

On 2024-02-08, Rainer Weikusat <rweikusat@talktalk.net> wrote:
> According to Ritchie's "The Development of the C Language"
>
> ,----
>| During 1973-1980, the language grew a bit: the type structure gained
>| unsigned
>|
>| [...]
>|
>| the similarity of the arithmetic properties of character pointers and
>| unsigned integers made it hard to resist the temptation to identify
>| them. The unsigned types were added to make unsigned arithmetic
>| available without confusing it with pointer manipulation. Similarly, the
>| early language condoned assignments between integers and pointers
> `----

It seems like a very odd rationale, given how things played out.

The difference between two pointers ended up signed (ptrdiff_t).
So pointer arithmetic doesn't work exactly like unsigned. That's mostly
a good thing, except that pointers farther from each other than half the
address space cannot be subtracted. (ISO C mostly takes that away anyway
since pointers to different objects may only be compared for exact
equality, and canno tbe subtracted. If no object is half the address
space or larger, subtraction overflow will never occur.)

Moreover, unsigned ended up necessary for representing a simple byte
in a nice way.

Not only that, but unsigned types are useful for bit manipulation,
without running into nonportable behaviors around shifting into and out
of the sign bit.

If you have a 32 bit int and want a 32 bit field, you want unsigned int.

Very odd to see the existence of unsigned math justified in terms of
some story about pointers.

It seems Ritchie really didn't think much about portability; he
probabably thought it was fine to do 1 << 15 with a 16 bit signed int
to calculate a mask for the highest bit, since that happened to work in
the systems he designed. If someone wanted C on their weird machine
where that misbehaves, or produces an alternative zero that compares
equal to regular zero, that was their problem.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On Thu, 08 Feb 2024 10:23:29 -0800, Keith Thompson wrote:

> The sentence "Whether or not sign-extension occurs for characters is
> machine dependent" might be written in more modern terms as "The
> signedness of char is implementation-defined".
>
> signed char and unsigned char (and unsigned short and unsigned long)
> were added in ANSI C 1989, possibly earlier.

Here’s an odd thing: what happens when you shift a signed int? K&R allows
left-shift with the obvious meaning, and says that, for right-shift,
whether the top bits are zero-filled or sign-extended is implementation-
defined; newer C specs say that left-shifting a negative value is simply
“undefined”, and right-shifting a negative value is “implementation-
defined”.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>On Thu, 08 Feb 2024 10:23:29 -0800, Keith Thompson wrote:
>
>> The sentence "Whether or not sign-extension occurs for characters is
>> machine dependent" might be written in more modern terms as "The
>> signedness of char is implementation-defined".
>>
>> signed char and unsigned char (and unsigned short and unsigned long)
>> were added in ANSI C 1989, possibly earlier.
>
>Here’s an odd thing: what happens when you shift a signed int? K&R allows
>left-shift with the obvious meaning, and says that, for right-shift,
>whether the top bits are zero-filled or sign-extended is implementation-
>defined; newer C specs say that left-shifting a negative value is simply
>“undefined”, and right-shifting a negative value is “implementation-
>defined”.

There were extant hardware implementations exhibiting both behaviors. So they
made the behavior implementation-defined in the compiler.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Thu, 08 Feb 2024 10:23:29 -0800, Keith Thompson wrote:
>> The sentence "Whether or not sign-extension occurs for characters is
>> machine dependent" might be written in more modern terms as "The
>> signedness of char is implementation-defined".
>>
>> signed char and unsigned char (and unsigned short and unsigned long)
>> were added in ANSI C 1989, possibly earlier.
>
> Here’s an odd thing: what happens when you shift a signed int? K&R allows
> left-shift with the obvious meaning, and says that, for right-shift,
> whether the top bits are zero-filled or sign-extended is implementation-
> defined; newer C specs say that left-shifting a negative value is simply
> “undefined”, and right-shifting a negative value is “implementation-
> defined”.

True. On the other hand, there are no shift operations on character
types (or short or unsigned short). The integer promotions are
performed on both operands of "<<" or ">>", so the value that's shifted
is at least as wide as int or unsigned int.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

On Thu, 08 Feb 2024 22:30:52 GMT, Scott Lurndal wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
>>Here’s an odd thing: what happens when you shift a signed int? K&R allows
>>left-shift with the obvious meaning, and says that, for right-shift,
>>whether the top bits are zero-filled or sign-extended is implementation-
>>defined; newer C specs say that left-shifting a negative value is simply
>>“undefined”, and right-shifting a negative value is “implementation-
>>defined”.
>
> There were extant hardware implementations exhibiting both behaviors.

Except the current spec doesn’t mention a choice between two behaviours.