Re: Computer architects leaving Intel...

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.