public inbox for newlib@sourceware.org
 help / color / mirror / Atom feed
From: "panda.trooper" <panda.trooper@protonmail.com>
To: newlib@sourceware.org
Subject: Re: Why int32_t is long int on 32 Bit Intel?
Date: Fri, 28 Jul 2023 08:06:15 +0000	[thread overview]
Message-ID: <hdgchCozJ-NJb1GySP6rwmX9Ber5xeOI5SWQGA9kgR71RObfjX2zy21mtDOwbEtc6NCsuO1JhM8hkKk6MFs6QMIPyuEXr3M-e-KUiG2P_n0=@protonmail.com> (raw)
In-Reply-To: <6408c9e9-6bae-1032-58f5-8b1a302b1756@Shaw.ca>

> 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.

  reply	other threads:[~2023-07-28  8:06 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-27 11:55 panda.trooper
2023-07-27 23:13 ` Brian Inglis
2023-07-28  8:06   ` panda.trooper [this message]
2023-07-28 13:23     ` Anders Montonen
2023-07-28 14:15       ` Joel Sherrill
2023-07-28 15:49         ` [EXTERNAL]: " Mike Burgess
2023-07-28 16:11           ` Stefan Tauner
2023-07-28 16:26             ` Mike Burgess
2023-07-28 17:06               ` Richard Damon
2023-07-28 18:05                 ` Grant Edwards
2023-07-28 18:27           ` panda.trooper
2023-07-28 20:23             ` Jon Beniston
2023-07-28 21:42               ` panda.trooper
2023-07-28 21:53                 ` Jon Beniston
2023-07-29 12:47                   ` Trampas Stern
2023-07-29 13:19                     ` Stefan Tauner
2023-07-29 21:21                     ` Grant Edwards

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='hdgchCozJ-NJb1GySP6rwmX9Ber5xeOI5SWQGA9kgR71RObfjX2zy21mtDOwbEtc6NCsuO1JhM8hkKk6MFs6QMIPyuEXr3M-e-KUiG2P_n0=@protonmail.com' \
    --to=panda.trooper@protonmail.com \
    --cc=newlib@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).