Hello all, I am not expert but I would like bring attention to some facts which come to my mind
On Monday 22 of August 2016 18:19:06 Andy Ross wrote: > --- a/gcc/config/newlib-stdint.h > +++ b/gcc/config/newlib-stdint.h > @@ -22,10 +22,9 @@ a copy of the GCC Runtime Library Exception along with > this program; see the files COPYING3 and COPYING.RUNTIME respectively. If > not, see <http://www.gnu.org/licenses/>. */ > > -/* newlib uses 32-bit long in certain cases for all non-SPU > - targets. */ > +/* newlib used to use a 32-bit long, no longer */ > #ifndef STDINT_LONG32 > -#define STDINT_LONG32 (LONG_TYPE_SIZE == 32) > +#define STDINT_LONG32 0 > #endif how this change would work on some H8 toolchain variants and for each MSP430 build. They have int type only 16 bits wide. If there is available INT_TYPE_SIZE #ifndef STDINT_LONG32 #define STDINT_LONG32 (INT_TYPE_SIZE < 32) #endif could be OK. But INT_TYPE_SIZE seems is not used/available in NewLib from the first glimpse. But you get into significant troubles on Windows platform with that probably because LONG is equivalent of int32_t on both 32-bit and 64-bit platform there and most of the APIs use it this way which means that all kind of warning would appear if uint32_t *ptr is passed to LONG *ptr used in API. It would change from long * and long * to int * and long * So I think that these problems should be considered before change. Limiting use of int for int32_t only to 64-bit targets with 64-bit long (as it is now) seems reasonable if used consistent way. Best wishes, Pavel
