Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Terje Mathisen <terje.mathisen@tmsw.no>
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Thu, 5 Sep 2024 11:12:04 +0200
Organization: A noiseless patient Spider
Lines: 121
Message-ID: <vbbsl4$9hdg$1@dont-email.me>
References: <2024Aug30.161204@mips.complang.tuwien.ac.at>
 <memo.20240830164247.19028y@jgd.cix.co.uk> <vasruo$id3b$1@dont-email.me>
 <2024Aug30.195831@mips.complang.tuwien.ac.at> <vat5ap$jthk$2@dont-email.me>
 <vaunhb$vckc$1@dont-email.me> <vautmu$vr5r$1@dont-email.me>
 <2024Aug31.170347@mips.complang.tuwien.ac.at> <vavpnh$13tj0$2@dont-email.me>
 <vb00c2$150ia$1@dont-email.me>
 <505954890d8461c1f4082b1beecd453c@www.novabbs.org>
 <vb0kh2$12ukk$1@dont-email.me> <vb3smg$1ta6s$1@dont-email.me>
 <vb4q5o$12ukk$3@dont-email.me> <vb6a16$38aj5$1@dont-email.me>
 <vb7evj$12ukk$4@dont-email.me> <vb8587$3gq7e$1@dont-email.me>
 <vb91e7$3o797$1@dont-email.me> <vb9eeh$3q993$1@dont-email.me>
 <vb9l7k$3r2c6$2@dont-email.me> <vba26l$3te44$1@dont-email.me>
 <vbag2s$3vhih$1@dont-email.me> <vbbnf9$8j04$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Injection-Date: Thu, 05 Sep 2024 11:12:05 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="857776fef6868ced66c218ce31d54b56";
	logging-data="312752"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18ZGT8mQ4cwpBd0Y+4qTyCZqUvLeFciQpf4kcXo9IHdaQ=="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Firefox/91.0 SeaMonkey/2.53.18.2
Cancel-Lock: sha1:h8k0tGZNSEs5P4rJ1lSg+AskdqU=
In-Reply-To: <vbbnf9$8j04$1@dont-email.me>
Bytes: 6105

David Brown wrote:
> On 04/09/2024 22:31, Brett wrote:
>> David Brown <david.brown@hesbynett.no> wrote:
>>> On 04/09/2024 14:53, jseigh wrote:
>>>> On 9/4/24 06:57, David Brown wrote:
>>>>> On 04/09/2024 09:15, Terje Mathisen wrote:
>>>>>> David Brown wrote:
>>>>
>>>>>> Maybe?
>>>>>>
>>>>>> Rust will _always_ check for such overflow in debug builds, then w=
hen
>>>>>> you've determined that they don't occur, the release build falls b=
ack
>>>>>> standard CPU behavior, i.e. wrapping around with no panics.
>>>>>
>>>>> But if you've determined that they do not occur (during debugging),=

>>>>> then your code never makes use of the results of an overflow - thus=

>>>>> why is it defined behaviour?=C3=82=C2=A0 It makes no sense.=C3=82=C2=
=A0 The only time when
>>>>> you would actually see wrapping in final code is if you hadn't test=
ed
>>>>> it properly, and then you can be pretty confident that the whole th=
ing
>>>>> will end in tears when signs change unexpectedly.=C3=82=C2=A0 It wo=
uld be much
>>>>> more sensible to leave signed overflow undefined, and let the compi=
ler
>>>>> optimise on that basis.
>>>>>
>>>>
>>>> You absolutely do want defined behavior on overflow.
>>>
>>> No, you absolutely do /not/ want that - for the vast majority of=20
>>> use-cases.
>>>
>>> There are times when you want wrapping behaviour, yes.=C2=A0 More gen=
erally,
>>> you want modulo arithmetic rather than a model of mathematical intege=
r
>>> arithmetic.=C2=A0 But those cases are rare, and in C they are easily =
handled
>>> using unsigned integers.
>>
>> I tried using unsigned for a bunch of my data types that should never =
go
>> negative, but every time I would have to compare them with an int=20
>> somewhere
>> and that would cause a compiler warning, because the goal was to also
>> remove unsafe code.
>>
>> Complete and udder disaster, went back to plain sized ints.
>>
>=20
> That's a matter of choice in the warnings you pick and the style you us=
e=20
> - these should match.
>=20
> However, I don't think C's integer promotion rules are ideal in regard =

> to mixing signed and unsigned arithmetic - converting both to "unsigned=
"=20
> can easily lead to trouble.
>=20
> Some people recommend using unsigned int everywhere you can, because th=
e=20
> overflow behaviour is defined - I think that is simply wrong.=C2=A0 Use=
=20
> unsigned int where it is appropriate, but it is very rare (though it=20
> happens sometimes) that you want any arithmetic to overflow in any way.=
=20
> So the justification is wrong.
>=20
> Some people like to use unsigned int when the values will not be=20
> negative.=C2=A0 I don't think that is a good idea either.=C2=A0 In gene=
ral, for=20
> any given use you only need a limited range of values.=C2=A0 0 to 10000=
 is=20
> just as much a subset of "int" as "unsigned int", and using "unsigned=20
> int" does not give any advantages.=C2=A0 On the contrary, using "int" c=
an=20
> give more efficient code in many places, and lets you enable warnings=20
> about mixed unsigned / signed operations for when you actually want the=
m.
>=20
> Unsigned types are ideal for "raw" memory access or external data, for =

> anything involving bit manipulation (use of &, |, ^, << and >> on signe=
d=20
> types is usually wrong, IMHO), as building blocks in extended arithmeti=
c=20
> types, for the few occasions when you want two's complement wrapping,=20
> and for the even fewer occasions when you actually need that last bit o=
f=20
> range.

That last paragraph enumerates pretty much all the uses I have for=20
integer-type variables, with (like Mitch) a few apis that use (-1) as an =

error signal that has to be handled with special code.

>=20
> It would be nice if C had subrange types like Pascal or Ada, but it doe=
s=20
> not.=C2=A0 Usually int - or sizeed ints - are the practical choice.


Agreed 100%

I wrote enough Pascal with ranged types that I got used to it, and found =

that I was missing the feature when I used C.

Terje

--=20
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"