This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: __PRIPTR for 32-bit archs
- From: Corinna Vinschen <vinschen at redhat dot com>
- To: newlib at sourceware dot org
- Date: Mon, 6 Feb 2012 11:40:09 +0100
- Subject: Re: __PRIPTR for 32-bit archs
- References: <20120205103024.GA12591@sgd-dalcoi5-20.ethz.ch>
- Reply-to: newlib at sourceware dot org
Hi,
On Feb 5 11:30, Kornilios Kourtis wrote:
> Hi,
>
> We are trying to use newlib in the Barrelfish research OS. Maybe I'm
> missing something, but I think that the current definition of __PRIPTR()
> in libc/include/inttypes.h is not correct for 32-bit archs.
>
> I believe this fixes it:
> --- src/newlib/libc/include/inttypes.h.orig 2012-02-04 15:00:18.943995069 +0100
> +++ src/newlib/libc/include/inttypes.h 2012-02-04 16:41:05.468106414 +0100
> @@ -242,16 +242,19 @@
> #define SCNxMAX __SCNMAX(x)
>
> /* ptr types */
> +#if defined(__PTRDIFF_TYPE__)
> #if __have_long64
> #define __PRIPTR(x) __STRINGIFY(l##x)
> #define __SCNPTR(x) __STRINGIFY(l##x)
> -#elif __have_longlong64
> -#define __PRIPTR(x) __STRINGIFY(ll##x)
> -#define __SCNPTR(x) __STRINGIFY(ll##x)
> #else
> #define __PRIPTR(x) __STRINGIFY(x)
> #define __SCNPTR(x) __STRINGIFY(x)
> #endif
> +#else /* !__PTRDIFF_TYPE__ */
> +/* hardcoded values for uintptr_t (see stdint.h) */
> +#define __PRIPTR(x) __STRINGIFY(l##x)
> +#define __SCNPTR(x) __STRINGIFY(l##x)
> +#endif
That wouldn't work for LLP64 systems, afaics. What about this? It
prefers using plain int over long long if the pointer size matches int
size. Only if that doesn't fit *and* __have_longlong64 is defined, we
use long long:
#if __have_long64
# define __PRIPTR(x) __STRINGIFY(l##x)
# define __SCNPTR(x) __STRINGIFY(l##x)
#elif PTRDIFF_MAX <= __STDINT_EXP(INT_MAX) || !defined(__have_longlong64)
# define __PRIPTR(x) __STRINGIFY(x)
# define __SCNPTR(x) __STRINGIFY(x)
#else
# define __PRIPTR(x) __STRINGIFY(ll##x)
# define __SCNPTR(x) __STRINGIFY(ll##x)
#endif
> Also, since gcc seems to define __INTPTR_TYPE__ these days, you might
Since when does gcc provide __INTPTR_TYPE__ and friends? Shouldn't
we fallback to __PTRDIFF_TYPE__ in the first place if __INTPTR_TYPE__
isn't defined?
Btw., would you mind to provide appropriate ChangeLog entries as well
when sending a patch?
Thanks,
Corinna
--
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat