From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-40137.protonmail.ch (mail-40137.protonmail.ch [185.70.40.137]) by sourceware.org (Postfix) with ESMTPS id 8C9D73858C20 for ; Fri, 28 Jul 2023 21:43:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8C9D73858C20 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 21:42:43 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1690580577; x=1690839777; bh=hQ3w9JZKCzy2P8/QTYcqVTbTFCdccSg0yXTAuu9XZ1o=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=YyQ8jz3IHBVl/RYrMu76MLNG6EI5iPogxBe+3cR7adtSqajYnWood+LHpSbAkPVJM 0M1qQT81OpwE3T0nlOcz3BRZl4/2aGQ2KHHk2DfQnnoGunrroXcmY9mr7rq7Xpoxa6 I1uhc4UxKJ1CQ8/d7Ls4oF8NHI9CfIcUWUyooa+lUhkq2A+SDsD4EvEml3XM39sCwR LQU6fHK4/G9PgzBJw6Qg98D2e9vh93WJ3O0s6l7vRyrc+GFXgn6rjjXeoXdgTEm3cl T64Ng0TaMGJ65cXje05rWWvrZXbo+HC6VTMKjOYDBuOkU+B+eMp/VlLJhjH0pBJrNX 8xN+sVzGuHtVw== To: Jon Beniston From: "panda.trooper" Cc: "newlib@sourceware.org" Subject: RE: [EXTERNAL]: Re: Why int32_t is long int on 32 Bit Intel? Message-ID: In-Reply-To: <0e3601d9c191$646f6160$2d4e2420$@beniston.com> References: <6408c9e9-6bae-1032-58f5-8b1a302b1756@Shaw.ca> <18BB0DD5-57EA-4B82-8807-72AEA51CA719@iki.fi> <5R8qxH6_HYtlUHJwlmty3kXezOsTViDs7SS5LKuaYjuv0deTlTbaqrPDHb9jMAlRkhEPjUvslRMThonV8TOEnmMvOXKFEAk5DZAGXvfmubA=@protonmail.com> <0e3601d9c191$646f6160$2d4e2420$@beniston.com> 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.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,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: Hi Jon, you are right, in recent GCC/newlib combinations it is GCC who decides by m= eans of setting __INT32_TYPE__, and newlib takes whatever is defined in __I= NT32_TYPE__. However, in older newlib versions this was not the case. In th= e good old days the decision was made like this (newlib/libc/include/stdint= .h in newlib version 1.18): /* Check if "long" is 64bit or 32bit wide */ #if __STDINT_EXP(LONG_MAX) > 0x7fffffff #define __have_long64 1 #elif __STDINT_EXP(LONG_MAX) =3D=3D 0x7fffffff && !defined(__SPU__) #define __have_long32 1 #endif [...] #if __have_long32 typedef signed long int32_t; typedef unsigned long uint32_t; #define __int32_t_defined 1 #elif __STDINT_EXP(INT_MAX) =3D=3D 0x7fffffffL typedef signed int int32_t; typedef unsigned int uint32_t; #define __int32_t_defined 1 [...] Please notice "&& !defined(__SPU__)", which is an very interesting exceptio= n from the default case. In gcc/config/newlib-stdint.h you find references = to this in form of the comment (just from before your excerpt): /* newlib uses 32-bit long in certain cases for all non-SPU targets. */ #ifndef STDINT_LONG32 #define STDINT_LONG32 (LONG_TYPE_SIZE =3D=3D 32) #endif So the roots of this decision are in the history of newlib. I also assumed = that those people who created gcc/config/newlib-stdint.h have quite some st= akes in newlib (or the other way around). That's why I asked in this commun= ity. Your explanation with Turbo C is also plausible. Thanks for that interestin= g insight. One final question: do you know what "SPU" means in this context and why it= is an exceptional case? Cheers, Zoltan ------- Original Message ------- On Friday, July 28th, 2023 at 22:23, Jon Beniston wrote: > > So again, just out of curiosity: what is the reason using long as int32= _t on an architecture where int is suitable, too? >=20 >=20 > Long ago, there were 32-bit x86 compilers where int was 16-bit (E.g. Turb= o C). >=20 > Also, are you sure it isn't gcc that's determining the type of int32_t ra= ther than Newlib? I've not used i686-elf-gcc, but for some targets newlib d= efines int32_t based on INT32_TYPE which is defined by gcc: >=20 > In gcc/config/newlib-stdint.h >=20 > #ifndef STDINT_LONG32 > #define STDINT_LONG32 (LONG_TYPE_SIZE =3D=3D 32) > #endif > ... > #define INT32_TYPE (STDINT_LONG32 ? "long int" : INT_TYPE_SIZE =3D=3D 32 = ? "int" : SHORT_TYPE_SIZE =3D=3D 32 ? "short int" : CHAR_TYPE_SIZE =3D=3D 3= 2 ? "signed char" : 0) >=20 > Cheers, > Jon