Why int32_t is long int on 32 Bit Intel?

[panda.trooper]

> On 2023-07-27 05:55, panda.trooper wrote:
> 
> > Hi, can somebody explain what is the reason behind the architectural decision that on x86 the type of int32_t is long int by default and not int when using newlib?
> 
> 
> Lots of embedded processors have 16 bit int and 32 bit long, and 80186
> compatibles are still being produced and sold, although gcc -m16 now has
> limitations.
> 
> [The ancient PDP-11 is still supported by gcc 13:
> 
> https://gcc.gnu.org/onlinedocs/gcc/gcc-command-options/machine-dependent-options/pdp-11-options.html
> 
> probably because it may still be exemplary CISC ISA in comp arch courses using
> simulators like SimH et al.]
> 
> --
> Take care. Thanks, Brian Inglis Calgary, Alberta, Canada
> 
> La perfection est atteinte Perfection is achieved
> non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add
> mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
> -- Antoine de Saint-Exupéry

Ok, I understand, some embedded systems have 16 bit int. But why not looking first if int is 32 bit and if yes, selecting that type as int32_t, and if the size doesn't fit, look for other types?

I am on x86 (32 bit) and have C++ code like this:

void foo(long) {}
void foo(int) {}

Now this compiles with bot, my native Linux GCC and with my newlib based i686-elf cross compiler. If I change this to this:

void foo(long) {}
void foo(int32_t) {}

then it will still compile with native Linux GCC (int32_t is int) but will fail with newlib i686-elf cross GCC, because both types are the same. The newlib behavior is kind of unintuitive to me. It is correct, because the standard only defines the size of the type, not the exact type. But I would not expect to get different types on the same CPU architecture with the same compiler just because I am using a different standard C library.

Is this expectation wrong? I am unsure.