From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-40130.protonmail.ch (mail-40130.protonmail.ch [185.70.40.130]) by sourceware.org (Postfix) with ESMTPS id 12656385AF9B for ; Fri, 28 Jul 2023 08:06:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 12656385AF9B Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=protonmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=protonmail.com Date: Fri, 28 Jul 2023 08:06:15 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1690531579; x=1690790779; bh=rDeXZwwbYzN6tpPeaSa34m3X7PGOT0Jtx8/EOEz76+k=; h=Date:To:From:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=GvZ7E0XZo34mS6C+2xfQb6GoCCFu+AcpAsvuRU5opvyhY8+e9S4altMJ211h/pwEP JhHjmzm8HKWbhglTfQshSbSR96a4PuJpgkeUsqXitBblNZ4NIIvAOpi2xmVkApWaoz sqCYGA9f+VBnCXamihThQFddLUDFiwdoaDoL6DU4oMQP4LlMvw4t+J+wDJ+gwx6N7f 8GgUBVvPObDSsP7RoABBHIqXCZ/aOn3zMob7Vh6haVEtRWtoMuQ40pkHdMyoJ3Jc5W t8x93PmN80mvZa5Xtck3CbeWmPRySYZs+38ORF+ZXZOgBoayHhU9MOKTux+3q8gqQW DFy+2JoV+ir6g== To: newlib@sourceware.org From: "panda.trooper" Subject: Re: Why int32_t is long int on 32 Bit Intel? Message-ID: In-Reply-To: <6408c9e9-6bae-1032-58f5-8b1a302b1756@Shaw.ca> References: <6408c9e9-6bae-1032-58f5-8b1a302b1756@Shaw.ca> Feedback-ID: 16995402:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_SHORT,RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: > On 2023-07-27 05:55, panda.trooper wrote: >=20 > > Hi, can somebody explain what is the reason behind the architectural de= cision that on x86 the type of int32_t is long int by default and not int w= hen using newlib? >=20 >=20 > 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. >=20 > [The ancient PDP-11 is still supported by gcc 13: >=20 > https://gcc.gnu.org/onlinedocs/gcc/gcc-command-options/machine-dependent-= options/pdp-11-options.html >=20 > probably because it may still be exemplary CISC ISA in comp arch courses = using > simulators like SimH et al.] >=20 > -- > Take care. Thanks, Brian Inglis Calgary, Alberta, Canada >=20 > La perfection est atteinte Perfection is achieved > non pas lorsqu'il n'y a plus rien =C3=A0 ajouter not when there is no mor= e to add > mais lorsqu'il n'y a plus rien =C3=A0 retirer but when there is no more t= o cut > -- Antoine de Saint-Exup=C3=A9ry Ok, I understand, some embedded systems have 16 bit int. But why not lookin= g 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 i6= 86-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 n= ewlib behavior is kind of unintuitive to me. It is correct, because the sta= ndard only defines the size of the type, not the exact type. But I would no= t 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.