Manfred <noname@add.invalid> writes:
> On 11/8/2021 7:33 PM, Tim Rentsch wrote:
>> Manfred <noname@add.invalid> writes:
>>> If it "can never overflow", it's a statement that is clear enough.
>> Note that the original code doesn't have any computations
>> involving unsigned operands, only signed operands.
>
> On 08/11/2021 12:11, Howerd Oakford wrote:
>
>> uint8_t i;
>
>
> The code does
>> have /conversions/ from one integer type to another, but
>> conversions have their own rules, and no conversion between
>> integer types, either signed or unsigned or both, is "overflow"
>> in the sense that the C standard uses the term. Converting to
>> an unsigned type (from another integer type) is always exactly
>> defined by the C standard, depending only on the value being
>> converted and the implementation-defined width of the unsigned
>> type that is the target type of the conversion.

I can guess at the point you were trying to make, but it would be better
to be explicit rather than quoting snippets from previous posts.

Tim is correct. There is not addition of uint8_t values. The uint8_t
value is promoted to int, 1 is added to it, and the result is converted
back to uint8_t.

--
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 08/11/2021 19:49, Manfred wrote:
> On 11/8/2021 7:33 PM, Tim Rentsch wrote:
>> Manfred <noname@add.invalid> writes:
>
>>
>>> If it "can never overflow", it's a statement that is clear enough.
>>
>> Note that the original code doesn't have any computations
>> involving unsigned operands, only signed operands.
>
> On 08/11/2021 12:11, Howerd Oakford wrote:
>
>>     uint8_t i;
>
>
>   The code does

It has a variable of an unsigned type, but no arithmetic using unsigned
operations. For "i++", the "uint8_t" value is promoted to "int". Then
one is added to this int value, and then the result is converted back to
uint8_t. It might seem strange, but that's the way C works. (This has
the side-effect that a statement like "i++;" for signed int8_t types
will be defined behaviour - implementation-dependent, but almost
invariably wrapping.)

On 08/11/2021 19:41, Keith Thompson wrote:
> scott@slp53.sl.home (Scott Lurndal) writes:
>> Meredith Montgomery <mmontgomery@levado.to> writes:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>
>>> [...]
>>>
>>>> The uint8_t variable counts up to 255, then wraps to 0 - overflow is
>>>> always wrapping for unsigned types (unlike for signed types).
>>>
>>> Technically the word is not ``overflow''.
>>
>> Technically, the processor sets the "overflow" flag. If that's not
>> an overflow, I'm not sure what it.
>
> Which processor? Who says it even has an overflow flag?
>

It is a ARM device. These have flags, including an overflow flag and a
carry flag (as Bonita pointed out, it would be the carry flag in this
case - the overflow flag is for signed arithmetic overflows).

However, as in many RISC architectures, updating the flags is optional
(using the ADDS instruction rather than ADD, IIRC) since flags are
scheduling bottlenecks. The compiler will not generate a flag-setting
ADD unless it needs one.

> In this context, "overflow" is determined by the C standard, not by the
> CPU.
>

Indeed.

On 08/11/2021 20:18, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 08/11/2021 12:11, Howerd Oakford wrote:
>>> Hi C-folks,
>>>
>>> Is the code listed below valid C?
>>> Specifically, is "i < 256" valid?
>>
>> It is valid, it is just not helpful. A uint8_t variable will /always/
>> be less than 256, so the check is always "true".
>>
>>>
>>> I ask this because i is an 8 bit unsigned integer, and I would like
>>> to know if it is legal to compare it with a value that is outside the
>>> range of i?
>>>
>>> Normally, I expect a for ... loop to count up to the value in the
>>> middle section, but in the case below it creates an infinite loop.
>>
>> The uint8_t variable counts up to 255, then wraps to 0 - overflow is
>> always wrapping for unsigned types (unlike for signed types).
>> Basically, you loop is like asking to run something every hour until 13
>> o'clock.
>
> That's essentially correct, but it's a bit more complicated for integer
> types narrower than int and unsigned int.
>
> You have:
>
> uint8_t i;
> ...
> i++
>
> C has no arithmetic operators for types narrower than int and unsigned
> int (and uint8_t is definitely narrower than int, since int is at least
> 16 bits).
>
> The expression `i++` is equivalent to `i = i + 1`. In `i + 1`, the
> value of i is promoted to int. The addition is then down on two
> operands of type int, and the result is assigned to i. Assigning an int
> value to a uint8_t object requires an implicit conversion. If the
> converted value can be represented in the target type (i.e., it's in the
> range 0..255), the conversion retains the same value. Otherwise, since
> the target type is an unsigned integer type, the conversion converts 256
> to 0. (It gets more complicated if the target type is a signed type
> like int8_t).
>
> The final result is the same as if it were operating directly on 8-bit
> values -- and the compiler might well generate code that does that if
> it's more efficient.
>

I know - but I didn't think the OP needed that level of detail. But if
he wants it, you've given an nice explanation of what is actually going on.

David Brown <david.brown@hesbynett.no> writes:

> On 08/11/2021 14:55, Meredith Montgomery wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>
>> [...]
>>
>>> The uint8_t variable counts up to 255, then wraps to 0 - overflow is
>>> always wrapping for unsigned types (unlike for signed types).
>>
>> Technically the word is not ``overflow''.
>
> Yes - you are technically correct. But at the the level of discussion
> that is most suitable for a thread like this, it is a useful term to
> describe what is happening. I don't think quoting the standard will
> help the OP.

I totally agree and my comment is not really for the OP. This is the
USENET, where sometimes an OP initiates a thread and people take it over
to just chat about whatever pleases them.

But, by the way, it does help the OP somewhat too. Even if the OP
doesn't understand the subject here, s/he gets a sense of the
complications that arise. (Tomorrow the OP might look up the word
overflow in an encyclopedia and check the standard to see if it
matches.)

Historically, comp.lang.c has always been more a group about the
standard than, say, practical c programming. Do you guys remember Dan
Pop? He used to amuse me. I like the language lawyers. I'm following
in their footsteps --- when I can, of course. It's fun.

Howerd Oakford <howerdo@gmail.com> writes:

> On Monday, November 8, 2021 at 1:59:20 PM UTC+1, David Brown wrote:

>> The big question is, why are you using "uint8_t" at all here?
> Company policy.

That's a shame. You can do this, of course,

uint8_t i = 0;
do {
// ... whatever ...
} while (i++ < UINT8_MAX);

but maybe company policy forbids this.

--
Ben.

On 08/11/2021 20:57, Meredith Montgomery wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 08/11/2021 14:55, Meredith Montgomery wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>
>>> [...]
>>>
>>>> The uint8_t variable counts up to 255, then wraps to 0 - overflow is
>>>> always wrapping for unsigned types (unlike for signed types).
>>>
>>> Technically the word is not ``overflow''.
>>
>> Yes - you are technically correct. But at the the level of discussion
>> that is most suitable for a thread like this, it is a useful term to
>> describe what is happening. I don't think quoting the standard will
>> help the OP.
>
> I totally agree and my comment is not really for the OP. This is the
> USENET, where sometimes an OP initiates a thread and people take it over
> to just chat about whatever pleases them.

Fair enough. And the OP may want to understand things in more detail,
or compare with other sources. The percentage of C programmers who
regularly look at the C standards is, however, pretty small.

>
> But, by the way, it does help the OP somewhat too. Even if the OP
> doesn't understand the subject here, s/he gets a sense of the
> complications that arise. (Tomorrow the OP might look up the word
> overflow in an encyclopedia and check the standard to see if it
> matches.)
>
> Historically, comp.lang.c has always been more a group about the
> standard than, say, practical c programming. Do you guys remember Dan
> Pop? He used to amuse me. I like the language lawyers. I'm following
> in their footsteps --- when I can, of course. It's fun.
>

Manfred <noname@add.invalid> writes:

> On 11/8/2021 7:33 PM, Tim Rentsch wrote:
>
>> Manfred <noname@add.invalid> writes:
>>
>>> If it "can never overflow", it's a statement that is clear enough.
>>
>> Note that the original code doesn't have any computations
>> involving unsigned operands, only signed operands.
>
> On 08/11/2021 12:11, Howerd Oakford wrote:
>
>> uint8_t i;
>
> The code does

Sorry about this. I think of you as one of the language experts in
comp.lang.{c,c++} so I didn't think a more complete explanation
would be needed. The computational operands are signed because
the uint8_t variable is promoted to int before the operations
take place. I (wrongly) thought you would immediately understand
what I was getting at. Again, sorry for my misunderstanding.

(Despite the above, I still think it's better to err on the side
of overestimating people's abilities than to underestimate them.)