From: david.brown@hesbynett.no   
      
   On 20/12/2025 17:19, bart wrote:   
   > On 19/12/2025 17:57, David Brown wrote:   
   >> On 19/12/2025 17:05, bart wrote:   
   >   
   > [Default size 'int' being 32 or 64 bits]   
   >   
   >>> Currently it works very well for my 64-bit product, but here C stops   
   >>> short at promoting only to 32 bits! (When 'int' is 32 bits.) So you   
   >>> have a mix of auto-promotion plus explicit casts to 64 bits.   
   >>>   
   >>   
   >> I think making "int" 64-bit would have been a bad choice overall for C.   
   >>   
   >> The key issue is that there is a conflict of uses and efficiency on   
   >> 64- bit processors between "a type that is fast and convenient for   
   >> local use" and "a type that is big enough to handle most numbers, and   
   >> fast and efficient for storage".  Data in memory, especially in   
   >> arrays, is more efficient if it is smaller   
   >   
   > Sure. Then you choose the smallest size that can represent all likely   
   > values.   
   >   
   > But if you don't know the range of values, would you just use 'int' and   
   > hope nothing is outside the i32 range? Or would you use 64 bits?   
   >   
      
   For me personally, I /do/ know the range of values when I write code,   
   and thus pick appropriate sizes.  But in general, 32-bit really is   
   enough for almost all cases.  It is extraordinarily rare that code will   
   come across a number that does not fit inside a 32-bit int, without the   
   programmer being fully aware of the situation.  (The exception is if the   
   programmer is doing some weird 1990's style uncontrolled conversions   
   between pointers/addresses and integer types.)   
      
   > If the latter, then a default i64 size (with a range /4 billion times   
   > wider/ than i32) can make more sense.   
   >   
   >> - 32-bit is still a good size for the majority of numbers stored in   
   >> memory.  For local variables in registers, or even on the stack, 64-   
   >> bit is more efficient on x86-64 as it avoids the need of any kind of   
   >> sign or zero extension or masking.   
   >   
   > One mild downside on x64 is the need for a 'REX' prefix on some   
   > instructions that work on 64-bits (to set the 'W' bit). Unless the   
   > instructions already use x64's 8 extra registers so the prefix is needed   
   > anyway.   
   >   
      
   You know the messy details of x86 machine code far better than I do.   
      
   >   
   >   
   >> However, given that such a large proportion of code was written with   
   >> the assumption that "int" always means 32-bit, it made sense to keep   
   >> it at 32-bit.   
   >   
   > Could the same assumptions have been made about 'long'? I guess was   
   > 'long' was 32 bits when 'int' was 16 bits, then when the latter became   
   > 32 bits, 'long' stayed the same...   
   >   
   > ...until 64 bit machines came along. Then 'int' stayed the same, but   
   > 'long' became 64 bits - on some OSes but not others!   
   >   
      
   "long" was made 64-bit on all sane 64-bit platforms (remember that x86   
   was late to that party), because at that time C had no other standard   
   way to describe a 64-bit type.  And even once C99 came along and "long   
   long" was standardised as being at least 64 bits, I'm sure you will   
   agree that "long long int" is not the nicest or clearest of type names!   
   When the decision was made to keep "int" at 32-bit on platforms that   
   moved to 64 bits (a decision that I think was correct overall, but not   
   without its disadvantages), making "long" 64-bit was definitely the   
   right move.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)