I've seen this somewhere or I wrote this some time in the past for some
reason and I can't see how this make sense any longer. In a procedure
to read a numeric string and turn it into a number, we need to convert
each char-digit to some kind of integer:

(uint64_t) (unsigned char) (s[pos] - '0');

But the double cast here seems odd. I could have written this by
copying it from somewhere else. Today, what I would write is just

(uint64_t) (s[pos] - '0');

Am I making a mistake now? I can't anything wrong with this. Isn't a
char just an int? I'm turning an int into an unsigned integer (of a
larger size).

Thank you!

On 03/01/2022 17:15, Meredith Montgomery wrote:
> I've seen this somewhere or I wrote this some time in the past for some
> reason and I can't see how this make sense any longer. In a procedure
> to read a numeric string and turn it into a number, we need to convert
> each char-digit to some kind of integer:
>
> (uint64_t) (unsigned char) (s[pos] - '0');
>
> But the double cast here seems odd. I could have written this by
> copying it from somewhere else. Today, what I would write is just
>
> (uint64_t) (s[pos] - '0');
>
> Am I making a mistake now? I can't anything wrong with this. Isn't a
> char just an int? I'm turning an int into an unsigned integer (of a
> larger size).

Have you tried it? With this code:

signed char c=-10;
printf("%llu\n", (unsigned long long) c);
printf("%llu\n", (unsigned long long) (unsigned char) c);

The output is

18446744073709551606
246

So clearly there's a difference.

(I used 'long long' so that I could use the llu print format with more
confidence.)

On 1/3/2022 9:15 AM, Meredith Montgomery wrote:
> I've seen this somewhere or I wrote this some time in the past for some
> reason and I can't see how this make sense any longer. In a procedure
> to read a numeric string and turn it into a number, we need to convert
> each char-digit to some kind of integer:
>
> (uint64_t) (unsigned char) (s[pos] - '0');
>
> But the double cast here seems odd. I could have written this by
> copying it from somewhere else. Today, what I would write is just
>
> (uint64_t) (s[pos] - '0');
>
> Am I making a mistake now? I can't anything wrong with this. Isn't a
> char just an int? I'm turning an int into an unsigned integer (of a
> larger size).

Yes, it does make sense. For example, if the outer type is wider than
the inner type, as in your example.

A cast to unsigned type is not just a conceptual type change. It also
might transform (wrap) the value in accordance with the rules of modulo
arithmetic, with modulo equal to 2^(type width).

So, the first cast is intended to wrap the value. The second cast is
intended to "expand" the result to a desired target type.

--
Best regards,
Andrey Tarasevich

Am 03.01.2022 um 18:15 schrieb Meredith Montgomery:
> I've seen this somewhere or I wrote this some time in the past for some
> reason and I can't see how this make sense any longer. In a procedure
> to read a numeric string and turn it into a number, we need to convert
> each char-digit to some kind of integer:
>
> (uint64_t) (unsigned char) (s[pos] - '0');

(s[pos] - '0') might me signed and without the cast to unsigned
char it might be sign-extended to int64_4 before it is converted
to uint64_t. But there are no guarantees when converting negative
values to unsigneds.

On 1/3/22 12:15 PM, Meredith Montgomery wrote:
> I've seen this somewhere or I wrote this some time in the past for some
> reason and I can't see how this make sense any longer. In a procedure
> to read a numeric string and turn it into a number, we need to convert
> each char-digit to some kind of integer:
>
> (uint64_t) (unsigned char) (s[pos] - '0');
>
> But the double cast here seems odd. I could have written this by
> copying it from somewhere else. Today, what I would write is just
>
> (uint64_t) (s[pos] - '0');
>
> Am I making a mistake now? I can't anything wrong with this. Isn't a
> char just an int? I'm turning an int into an unsigned integer (of a
> larger size).
>
> Thank you!

As others have said, it does change the behavior, but only if s[pos]
might be less than '0', which means it holds something other than a
digit, as the characters 0..9 are a required to be a consecutive
increase sequence (which the code is likely counting on).

If you know that s[pos] will always be > 0, then the double cast may
produce faster code, as unless the compiler can also determine this, it
may need to first sign extend to int, then zero extend to uint64_t,
verse just zero extending to uint64_t.

Bart <bc@freeuk.com> writes:

> On 03/01/2022 17:15, Meredith Montgomery wrote:
>> I've seen this somewhere or I wrote this some time in the past for some
>> reason and I can't see how this make sense any longer. In a procedure
>> to read a numeric string and turn it into a number, we need to convert
>> each char-digit to some kind of integer:
>> (uint64_t) (unsigned char) (s[pos] - '0');
>> But the double cast here seems odd. I could have written this by
>> copying it from somewhere else. Today, what I would write is just
>> (uint64_t) (s[pos] - '0');
>> Am I making a mistake now? I can't anything wrong with this. Isn't
>> a
>> char just an int? I'm turning an int into an unsigned integer (of a
>> larger size).
>
> Have you tried it? With this code:
>
> signed char c=-10;
> printf("%llu\n", (unsigned long long) c);
> printf("%llu\n", (unsigned long long) (unsigned char) c);
>
> The output is
>
> 18446744073709551606
> 246
>
> So clearly there's a difference.

Indeed. Thank you. I had tried it, but I wasn't quite thinking of
negative numbers because I was thinking of just my chars and my chars
are never negative. So the purpose there is to not let the number grow
to 64 bits. That's my understanding right now. Thank you.

Andrey Tarasevich <andreytarasevich@hotmail.com> writes:

> On 1/3/2022 9:15 AM, Meredith Montgomery wrote:
>> I've seen this somewhere or I wrote this some time in the past for some
>> reason and I can't see how this make sense any longer. In a procedure
>> to read a numeric string and turn it into a number, we need to convert
>> each char-digit to some kind of integer:
>> (uint64_t) (unsigned char) (s[pos] - '0');
>> But the double cast here seems odd. I could have written this by
>> copying it from somewhere else. Today, what I would write is just
>> (uint64_t) (s[pos] - '0');
>> Am I making a mistake now? I can't anything wrong with this. Isn't
>> a
>> char just an int? I'm turning an int into an unsigned integer (of a
>> larger size).
>
> Yes, it does make sense. For example, if the outer type is wider than
> the inner type, as in your example.
>
> A cast to unsigned type is not just a conceptual type change. It also
> might transform (wrap) the value in accordance with the rules of
> modulo arithmetic, with modulo equal to 2^(type width).
>
> So, the first cast is intended to wrap the value. The second cast is
> intended to "expand" the result to a desired target type.

Interesting. I got another question here. If s[pos] is always a char
and '0' is always a char, then s[pos] - '0' will never be greater than a
char. It might be negative. If it's negative and if I do

(unsigner char) s[pos] - '0',

can this do any wrapping at all? I'd say not in this case. I think you
are in more general waters than I took your message. Can you clarify a
bit? I'm a bit lost.

Bonita Montero <Bonita.Montero@gmail.com> writes:

> Am 03.01.2022 um 18:15 schrieb Meredith Montgomery:
>> I've seen this somewhere or I wrote this some time in the past for some
>> reason and I can't see how this make sense any longer. In a procedure
>> to read a numeric string and turn it into a number, we need to convert
>> each char-digit to some kind of integer:
>> (uint64_t) (unsigned char) (s[pos] - '0');
>
> (s[pos] - '0') might me signed and without the cast to unsigned
> char it might be sign-extended to int64_4 before it is converted
> to uint64_t. But there are no guarantees when converting negative
> values to unsigneds.

Really, no guarantees? So a procedure that does

(uint64_t) (unsigned char) (s[pos] - '0')

is not a C program if a machine uses negative numbers for chars?

Richard Damon <Richard@Damon-Family.org> writes:

> On 1/3/22 12:15 PM, Meredith Montgomery wrote:
>> I've seen this somewhere or I wrote this some time in the past for some
>> reason and I can't see how this make sense any longer. In a procedure
>> to read a numeric string and turn it into a number, we need to convert
>> each char-digit to some kind of integer:
>> (uint64_t) (unsigned char) (s[pos] - '0');
>> But the double cast here seems odd. I could have written this by
>> copying it from somewhere else. Today, what I would write is just
>> (uint64_t) (s[pos] - '0');
>> Am I making a mistake now? I can't anything wrong with this. Isn't
>> a
>> char just an int? I'm turning an int into an unsigned integer (of a
>> larger size).
>> Thank you!
>
> As others have said, it does change the behavior, but only if s[pos]
> might be less than '0', which means it holds something other than a
> digit, as the characters 0..9 are a required to be a consecutive
> increase sequence (which the code is likely counting on).
>
> If you know that s[pos] will always be > 0, then the double cast may
> produce faster code, as unless the compiler can also determine this,
> it may need to first sign extend to int, then zero extend to uint64_t,
> verse just zero extending to uint64_t.

What do you mean by ``zero extend''? Are you qualifying the verb ``to
extend''? You lost me there. Thank you.

On 1/15/22 8:15 PM, Meredith Montgomery wrote:
> Richard Damon <Richard@Damon-Family.org> writes:
>
>> On 1/3/22 12:15 PM, Meredith Montgomery wrote:
>>> I've seen this somewhere or I wrote this some time in the past for some
>>> reason and I can't see how this make sense any longer. In a procedure
>>> to read a numeric string and turn it into a number, we need to convert
>>> each char-digit to some kind of integer:
>>> (uint64_t) (unsigned char) (s[pos] - '0');
>>> But the double cast here seems odd. I could have written this by
>>> copying it from somewhere else. Today, what I would write is just
>>> (uint64_t) (s[pos] - '0');
>>> Am I making a mistake now? I can't anything wrong with this. Isn't
>>> a
>>> char just an int? I'm turning an int into an unsigned integer (of a
>>> larger size).
>>> Thank you!
>>
>> As others have said, it does change the behavior, but only if s[pos]
>> might be less than '0', which means it holds something other than a
>> digit, as the characters 0..9 are a required to be a consecutive
>> increase sequence (which the code is likely counting on).
>>
>> If you know that s[pos] will always be > 0, then the double cast may
>> produce faster code, as unless the compiler can also determine this,
>> it may need to first sign extend to int, then zero extend to uint64_t,
>> verse just zero extending to uint64_t.
>
> What do you mean by ``zero extend''? Are you qualifying the verb ``to
> extend''? You lost me there. Thank you.

When the processor loads the 8 bit character into the bottom of the
register, it generally leaves the rest of the register alone.

If Char is signed, and int is 32 bits, then the implementation can
convert it to an int by extending the sign of the bottom byte into the
rest of the register, and then to make it a unsigned 54 bit value, it
needs to put zeros into the upper 32 bits of the register.

By casting to unsigned character, then the implentation only needs to
use an instruction that fills the upper 56 bits of the register to 0.

Setting the upper bits of a register with a value is called 'extending'

If it is copying the sign bit of the lower part of the register, it is
called sign extending.

If it is just fixing them to zero, it is called zero extending, because
we are thinking of the always 0 'sign bits' that extend beyond the bits
of the unsigned value.

Meredith Montgomery <mmontgomery@levado.to> writes:

> I've seen this somewhere or I wrote this some time in the past for some
> reason and I can't see how this make sense any longer. In a procedure
> to read a numeric string and turn it into a number, we need to convert
> each char-digit to some kind of integer:
>
> (uint64_t) (unsigned char) (s[pos] - '0');
>
> But the double cast here seems odd. I could have written this by
> copying it from somewhere else. Today, what I would write is just
>
> (uint64_t) (s[pos] - '0');
>
> Am I making a mistake now? I can't anything wrong with this. Isn't a
> char just an int? I'm turning an int into an unsigned integer (of a
> larger size).

The original context for the expression in question is this
function:

> [posted by Meredith Montgomery]
>
> #include <limits.h>
> #include <inttypes.h>
>
> int scan_ulong(register char *s, register unsigned long *u)
> {
> register unsigned int pos;
> register unsigned long r;
> register unsigned long c;
>
> pos = 0; r = 0;
>
> for ( ;; ) {
> c = (unsigned long) (unsigned char) (s[pos] - '0');
> if (c < 10) {
> if( ((ULONG_MAX - c) / 10) >= r)
> r = r * 10 + c;
> else return -1; /* lack of space */
> ++pos; continue;
> }
> break;
> }
>
> *u = r;
> return pos;
> }

In this context, the casts are superfluous. Just write

c = s[pos] - '0';

and the right thing will happen, because the assignment to 'c'
converts the value on the right hand side to 'unsigned long',
and so takes care of any negative values.

On 1/15/22 8:12 PM, Meredith Montgomery wrote:
....
> Interesting. I got another question here. If s[pos] is always a char
> and '0' is always a char, then s[pos] - '0' will never be greater than a
> char. It might be negative. If it's negative and if I do

Note that while members of the basic character set are required to be
represented by non-negative values (6.2.5p3), members of the extended
character set are not. If char is signed, they can be as low as
CHAR_MIN, in which case subtracting '0' necessarily results in undefined
behavior. The following discussion applies only when that isn't the case:

> (unsigner char) s[pos] - '0',
>
> can this do any wrapping at all? I'd say not in this case. I think you
> are in more general waters than I took your message. Can you clarify a
> bit? I'm a bit lost.

Subtraction involves (6.5p6) the usual arithmetic conversions
(6.3.1.8p1), and the first part of that is the integer promotions
(6.3.1.1p2). Both overflow and wrap-around are possible results, but
only on systems where CHAR_BIT >= 16. Such systems do exist - the ones
I've heard of are embedded systems specialized for digital signal
processing.

If all values of type unsigned char can be represented as an int,
(unsigned char)s[pos] will be promoted to int before performing the
subtraction (6.3.1.1p2). In the unlikely event that CHAR_MAX == INT_MAX,
(int)(unsigned char)s[pos] will have the same value as s[pos].
Therefore, if s[pos] is sufficiently close to INT_MIN, subtracting '0'
from it will have undefined behavior.

In the unlikely event that UCHAR_MAX > INT_MAX, s[pos] is promoted to an
unsigned int (6.3.1.1p2). Since '0' has the type 'int', and 'int' and
unsigned int' have the same integer conversion rank, the usual
arithmetic conversions specify that '0' is converted to unsigned int,
and the subtraction is carried out in that type. If s[pos] is less than
'0', then s[pos] - '0' will have a mathematical value that is negative,
so it will have to wrap around.

Am 03.01.2022 um 20:37 schrieb Richard Damon:

> If you know that s[pos] will always be > 0, then the double cast may
> produce faster code, as unless the compiler can also determine this,
> it may need to first sign extend to int, then zero extend to uint64_t,
> verse just zero extending to uint64_t.

On x86 there are widening-instructions to zero- / sign-extend a shorter
value which have all the same performance.

On 1/15/22 8:14 PM, Meredith Montgomery wrote:
> Bonita Montero <Bonita.Montero@gmail.com> writes:
>
>> Am 03.01.2022 um 18:15 schrieb Meredith Montgomery:
>>> I've seen this somewhere or I wrote this some time in the past for some
>>> reason and I can't see how this make sense any longer. In a procedure
>>> to read a numeric string and turn it into a number, we need to convert
>>> each char-digit to some kind of integer:
>>> (uint64_t) (unsigned char) (s[pos] - '0');
>>
>> (s[pos] - '0') might me signed and without the cast to unsigned
>> char it might be sign-extended to int64_4 before it is converted
>> to uint64_t. ...

He's right about it being signed - that's normally the case. It normally
has the type `int`, except in the extremely unlikely case that CHAR_MAX
> INT_MAX, in which case it will have the type `unsigned int`. However,
int64_t comes into play only if it's typedef for `int`.

>> ... But there are no guarantees when converting negative
>> values to unsigneds.
>
> Really, no guarantees? So a procedure that does

No, Bonita is mistaken. The standard provides a strong explicit
guarantee of what the behavior is when converting negative values to
unsigned type:

"... the value is converted by repeatedly adding ... one more than the
maximum value that can be represented in the new type until the value is
in the range of the new type." (6.3.1.3p2).

It's the other direction that's dangerous: conversion of an integer
value to a signed integer type that is not representable in that type
has undefined behavior.

James Kuyper <jameskuyper@alumni.caltech.edu> writes:
[...]
> "... the value is converted by repeatedly adding ... one more than the
> maximum value that can be represented in the new type until the value is
> in the range of the new type." (6.3.1.3p2).
>
> It's the other direction that's dangerous: conversion of an integer
> value to a signed integer type that is not representable in that type
> has undefined behavior.

No, converting an out-of-range integer value to a signed integer type
yields an implementation-defined result or raises an
implementation-defined signal. (C99 added the option of raising a
signal; in my opinion that was a bad idea.)

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

On 1/16/22 4:30 PM, Keith Thompson wrote:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> [...]
>> "... the value is converted by repeatedly adding ... one more than the
>> maximum value that can be represented in the new type until the value is
>> in the range of the new type." (6.3.1.3p2).
>>
>> It's the other direction that's dangerous: conversion of an integer
>> value to a signed integer type that is not representable in that type
>> has undefined behavior.
>
> No, converting an out-of-range integer value to a signed integer type
> yields an implementation-defined result or raises an
> implementation-defined signal. (C99 added the option of raising a
> signal; in my opinion that was a bad idea.)

Sorry - you're correct, and I actually knew that - but I was too tired
when I wrote that message.

James Kuyper <jameskuyper@alumni.caltech.edu> writes:

> On 1/15/22 8:14 PM, Meredith Montgomery wrote:
>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>
>>> Am 03.01.2022 um 18:15 schrieb Meredith Montgomery:
>>>> I've seen this somewhere or I wrote this some time in the past for some
>>>> reason and I can't see how this make sense any longer. In a procedure
>>>> to read a numeric string and turn it into a number, we need to convert
>>>> each char-digit to some kind of integer:
>>>> (uint64_t) (unsigned char) (s[pos] - '0');
>>>
>>> (s[pos] - '0') might me signed and without the cast to unsigned
>>> char it might be sign-extended to int64_4 before it is converted
>>> to uint64_t. ...
>
> He's right about it being signed - that's normally the case. It normally
> has the type `int`, except in the extremely unlikely case that CHAR_MAX
>> INT_MAX, in which case it will have the type `unsigned int`. However,
> int64_t comes into play only if it's typedef for `int`.
>
>>> ... But there are no guarantees when converting negative
>>> values to unsigneds.
>>
>> Really, no guarantees? So a procedure that does
>
> No, Bonita is mistaken. The standard provides a strong explicit
> guarantee of what the behavior is when converting negative values to
> unsigned type:
>
> "... the value is converted by repeatedly adding ... one more than the
> maximum value that can be represented in the new type until the value is
> in the range of the new type." (6.3.1.3p2).
>
> It's the other direction that's dangerous: conversion of an integer
> value to a signed integer type that is not representable in that type
> has undefined behavior.

That makes perfect sense. Thanks for the info. Very appreciated.

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> [...]
>> "... the value is converted by repeatedly adding ... one more than the
>> maximum value that can be represented in the new type until the value is
>> in the range of the new type." (6.3.1.3p2).
>>
>> It's the other direction that's dangerous: conversion of an integer
>> value to a signed integer type that is not representable in that type
>> has undefined behavior.
>
> No, converting an out-of-range integer value to a signed integer type
> yields an implementation-defined result or raises an
> implementation-defined signal. (C99 added the option of raising a
> signal; in my opinion that was a bad idea.)

Just curious --- why do you think a signal is a bad idea?

Richard Damon <Richard@Damon-Family.org> writes:

> On 1/15/22 8:15 PM, Meredith Montgomery wrote:
>> Richard Damon <Richard@Damon-Family.org> writes:
>>
>>> On 1/3/22 12:15 PM, Meredith Montgomery wrote:
>>>> I've seen this somewhere or I wrote this some time in the past for some
>>>> reason and I can't see how this make sense any longer. In a procedure
>>>> to read a numeric string and turn it into a number, we need to convert
>>>> each char-digit to some kind of integer:
>>>> (uint64_t) (unsigned char) (s[pos] - '0');
>>>> But the double cast here seems odd. I could have written this by
>>>> copying it from somewhere else. Today, what I would write is just
>>>> (uint64_t) (s[pos] - '0');
>>>> Am I making a mistake now? I can't anything wrong with this. Isn't
>>>> a
>>>> char just an int? I'm turning an int into an unsigned integer (of a
>>>> larger size).
>>>> Thank you!
>>>
>>> As others have said, it does change the behavior, but only if s[pos]
>>> might be less than '0', which means it holds something other than a
>>> digit, as the characters 0..9 are a required to be a consecutive
>>> increase sequence (which the code is likely counting on).
>>>
>>> If you know that s[pos] will always be > 0, then the double cast may
>>> produce faster code, as unless the compiler can also determine this,
>>> it may need to first sign extend to int, then zero extend to uint64_t,
>>> verse just zero extending to uint64_t.
>> What do you mean by ``zero extend''? Are you qualifying the verb
>> ``to
>> extend''? You lost me there. Thank you.
>
> When the processor loads the 8 bit character into the bottom of the
> register, it generally leaves the rest of the register alone.
>
> If Char is signed, and int is 32 bits, then the implementation can
> convert it to an int by extending the sign of the bottom byte into the
> rest of the register, and then to make it a unsigned 54 bit value, it
> needs to put zeros into the upper 32 bits of the register.
>
> By casting to unsigned character, then the implentation only needs to
> use an instruction that fills the upper 56 bits of the register to 0.
>
> Setting the upper bits of a register with a value is called 'extending'
>
> If it is copying the sign bit of the lower part of the register, it is
> called sign extending.
>
> If it is just fixing them to zero, it is called zero extending,
> because we are thinking of the always 0 'sign bits' that extend beyond
> the bits of the unsigned value.

Awesome information. Thank you so much.

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

> Meredith Montgomery <mmontgomery@levado.to> writes:
>
>> I've seen this somewhere or I wrote this some time in the past for some
>> reason and I can't see how this make sense any longer. In a procedure
>> to read a numeric string and turn it into a number, we need to convert
>> each char-digit to some kind of integer:
>>
>> (uint64_t) (unsigned char) (s[pos] - '0');
>>
>> But the double cast here seems odd. I could have written this by
>> copying it from somewhere else. Today, what I would write is just
>>
>> (uint64_t) (s[pos] - '0');
>>
>> Am I making a mistake now? I can't anything wrong with this. Isn't a
>> char just an int? I'm turning an int into an unsigned integer (of a
>> larger size).
>
> The original context for the expression in question is this
> function:
>
>> [posted by Meredith Montgomery]
>>
>> #include <limits.h>
>> #include <inttypes.h>
>>
>> int scan_ulong(register char *s, register unsigned long *u)
>> {
>> register unsigned int pos;
>> register unsigned long r;
>> register unsigned long c;
>>
>> pos = 0; r = 0;
>>
>> for ( ;; ) {
>> c = (unsigned long) (unsigned char) (s[pos] - '0');
>> if (c < 10) {
>> if( ((ULONG_MAX - c) / 10) >= r)
>> r = r * 10 + c;
>> else return -1; /* lack of space */
>> ++pos; continue;
>> }
>> break;
>> }
>>
>> *u = r;
>> return pos;
>> }
>
> In this context, the casts are superfluous. Just write
>
> c = s[pos] - '0';
>
> and the right thing will happen, because the assignment to 'c'
> converts the value on the right hand side to 'unsigned long',
> and so takes care of any negative values.

Oh, interesting! Thanks! I did not think of that.

Meredith Montgomery <mmontgomery@levado.to> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>> [...]
>>> "... the value is converted by repeatedly adding ... one more than the
>>> maximum value that can be represented in the new type until the value is
>>> in the range of the new type." (6.3.1.3p2).
>>>
>>> It's the other direction that's dangerous: conversion of an integer
>>> value to a signed integer type that is not representable in that type
>>> has undefined behavior.
>>
>> No, converting an out-of-range integer value to a signed integer type
>> yields an implementation-defined result or raises an
>> implementation-defined signal. (C99 added the option of raising a
>> signal; in my opinion that was a bad idea.)
>
> Just curious --- why do you think a signal is a bad idea?

A signal isn't inherently a bad idea, particularly if portable code can
handle it. But the fact that the signal is implementation-defined makes
that impossible. (And freestanding implementations needn't support
<signal.h>.)

And I've never heard of an implementation that raises a signal on an out
of range conversion, so having that option has not turned out to be
useful.

To make it potentially useful, the standard could have required a
specific signal to be raised (say, SIGCONV, which could be an alias for
some other signal), and specified a predefined macro that tells you
which choice the implementation made.

Even more useful would be to require the signal (but that would break
existing code) or provide a mechanism to enable it (but that might be
too great a burden on existing implementations). But again, that would
leave freestanding implementations out in the cold.

Reliable handling of numeric overflow has always been difficult in C.
This feature seems like a single very small step in making it easier,
but without more complete support I think it would have been better to
leave it the way it was in C90.

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

James Kuyper <jameskuyper@alumni.caltech.edu> writes:

> On 1/15/22 8:12 PM, Meredith Montgomery wrote:
> ...
>
>> Interesting. I got another question here. If s[pos] is always a char
>> and '0' is always a char, then s[pos] - '0' will never be greater than a
>> char. It might be negative. If it's negative and if I do
>
> Note that while members of the basic character set are required to be
> represented by non-negative values (6.2.5p3), members of the extended
> character set are not. If char is signed, they can be as low as
> CHAR_MIN, in which case subtracting '0' necessarily results in undefined
> behavior. [...]

No, it doesn't. Subtracting one character value from another can
give undefined behavior, but it doesn't have to, and indeed
usually cannot. The only circumstance where it can is when char
is signed and CHAR_MAX == INT_MAX.

On Thursday, January 20, 2022 at 10:37:33 PM UTC-5, Tim Rentsch wrote:
> James Kuyper <james...@alumni.caltech.edu> writes:
....
> > Note that while members of the basic character set are required to be
> > represented by non-negative values (6.2.5p3), members of the extended
> > character set are not. If char is signed, they can be as low as
> > CHAR_MIN, in which case subtracting '0' necessarily results in undefined
> > behavior. [...]

As Keith pointed out (and I had already conceded four days before your
message) that was a mistake on my part - the relevant clause says
"Otherwise, the new type is signed and the value cannot be represented in it;
either the result is implementation-defined or an implementation-defined
signal is raised." (6.3.1.3p3).

> No, it doesn't. Subtracting one character value from another can
> give undefined behavior, but it doesn't have to, and indeed
> usually cannot. The only circumstance where it can is when char
> is signed and CHAR_MAX == INT_MAX.

You're right - I was thinking about the possibility that CHAR_MAX == INT_MAX,
but I forgot to specify that this was a pre-condition for my claim that the
undefined behavior (which should instead have been a referrence to
6.3.1.3p3) was necessarily the result. Thank you for pointing this out.

"james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> writes:

> On Thursday, January 20, 2022 at 10:37:33 PM UTC-5, Tim Rentsch wrote:
>
>> James Kuyper <james...@alumni.caltech.edu> writes:
>
> ...
>
>>> Note that while members of the basic character set are
>>> required to be represented by non-negative values (6.2.5p3),
>>> members of the extended character set are not. If char is
>>> signed, they can be as low as CHAR_MIN, in which case
>>> subtracting '0' necessarily results in undefined behavior.
>>> [...]
>
> As Keith pointed out (and I had already conceded four days
> before your message) that was a mistake on my part - the
> relevant clause says "Otherwise, the new type is signed and the
> value cannot be represented in it; either the result is
> implementation-defined or an implementation-defined signal is
> raised." (6.3.1.3p3).

I noticed that, and saw Keith's response, and so chose not to
post a followup myself. But I wasn't saying anything about
converting back to a char, just about the subtraction.

>> No, it doesn't. Subtracting one character value from another can
>> give undefined behavior, but it doesn't have to, and indeed
>> usually cannot. The only circumstance where it can is when char
>> is signed and CHAR_MAX == INT_MAX.
>
> You're right - I was thinking about the possibility that
> CHAR_MAX == INT_MAX, but I forgot to specify that this was a
> pre-condition for my claim that the undefined behavior (which
> should instead have been a referrence to 6.3.1.3p3) was
> necessarily the result. Thank you for pointing this out.

I was confident you would understand the point once I mentioned
it. The followup was meant mainly for other readers who may
have been confused.

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Meredith Montgomery <mmontgomery@levado.to> writes:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>>> [...]
>>>> "... the value is converted by repeatedly adding ... one more than the
>>>> maximum value that can be represented in the new type until the value is
>>>> in the range of the new type." (6.3.1.3p2).
>>>>
>>>> It's the other direction that's dangerous: conversion of an integer
>>>> value to a signed integer type that is not representable in that type
>>>> has undefined behavior.
>>>
>>> No, converting an out-of-range integer value to a signed integer type
>>> yields an implementation-defined result or raises an
>>> implementation-defined signal. (C99 added the option of raising a
>>> signal; in my opinion that was a bad idea.)
>>
>> Just curious --- why do you think a signal is a bad idea?
>
> A signal isn't inherently a bad idea, particularly if portable code can
> handle it. But the fact that the signal is implementation-defined makes
> that impossible. (And freestanding implementations needn't support
> <signal.h>.)

What's a freestanding implementation?