Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Thu, 5 Sep 2024 16:01:26 +0200
Organization: A noiseless patient Spider
Lines: 54
Message-ID: <vbcdjm$bd22$6@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>
 <vb2hir$1ju7q$1@dont-email.me> <jwv34mgo7sz.fsf-monnier+comp.arch@gnu.org>
 <9a76aa4fdf15830a4b89aaca28e72754@www.novabbs.org>
 <vb927t$3nlvo$5@dont-email.me>
 <5b0afc722e98a2f3caa6aea97c77ab8a@www.novabbs.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 05 Sep 2024 16:01:26 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="622309b8b3e203ac6e38dece30d12fb2";
	logging-data="373826"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19XsbkZKoNZvHKv9cqX1HyHPpN3ASlQdSg="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:IAg53p1SZ0UojXsF8lWRQ3rR1xc=
Content-Language: en-GB
In-Reply-To: <5b0afc722e98a2f3caa6aea97c77ab8a@www.novabbs.org>
Bytes: 3651

On 04/09/2024 18:32, MitchAlsup1 wrote:
> On Wed, 4 Sep 2024 7:29:01 +0000, David Brown wrote:
> 
>> On 03/09/2024 22:22, MitchAlsup1 wrote:
>>> On Tue, 3 Sep 2024 19:30:21 +0000, Stefan Monnier wrote:
>>>
>>>>> Specifications are an agreement between the supplier and the 
>>>>> client. The
>>>>
>>>> The problem here is that the C standard, seen as a contract, is unfair
>>>> to the programmer, because it's so excruciatingly hard to write code
>>>> that is guaranteed to be free from UB.
>>>
>>> # define int int64_t
>>> ..
>>>
>>> makes it easier.
>>
>> That's UB, I believe :-)  And it will certainly be confusing.
> 
> On 64-bit machines it re-establishes the dusty-deck old K&R C where
> int was the fastest integer type.
> 

No, it does not.  It gives you an inconsistent mess and opens up all 
sorts of potential complications when interacting with code that uses 
"int" properly.  It does not help you avoid UB - it creates a lot more 
potential for mistakes.

Now, if you had suggested that we'd have been better off if the powers 
that be had made int 64-bit on 64-bit targets, then it would be a very 
different matter.  It would reduce the risk of UB from signed integer 
overload quite considerably - few numbers are big enough to overflow 64 
bits without being so big that you are using multi-precision numerics 
libraries anyway.

It would also mean that a lot of existing code that incorrectly or 
non-portably assumes "int" is 32-bit, would fail to work on the new systems.

We can't change existing non-portable code.  We can't change existing 
ABI's for 64-bit targets.  Slapping a #define band-aid on the code will 
not fix anything.

A better answer is it use int_fastNN_t types in your own code, picking a 
size that matches what you actually need.  (Perhaps limit it to 32 or 
64, to be portable to most systems - or just 64 if you really are sure 
the code will not be used on smaller targets.)  int_fast32_t and 
int_fast64_t are both 64-bit on x86-64.