This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: h8300, m32c and PRIuPTR
- From: Joseph Myers <joseph at codesourcery dot com>
- To: <newlib at sourceware dot org>
- Date: Tue, 17 Mar 2015 16:09:30 +0000
- Subject: Re: h8300, m32c and PRIuPTR
- Authentication-results: sourceware.org; auth=none
- References: <20150316150842 dot GI6096 at calimero dot vinschen dot de> <5506FCAA dot 8030403 at oarcorp dot com> <20150316161732 dot GJ6096 at calimero dot vinschen dot de> <55070486 dot 8060503 at oarcorp dot com> <20150316164918 dot GK6096 at calimero dot vinschen dot de> <55071AC5 dot 40104 at oarcorp dot com> <1426533957 dot 8104 dot 52 dot camel at redhat dot com> <55072FBB dot 8080107 at oarcorp dot com> <1426535357 dot 8104 dot 60 dot camel at redhat dot com> <55073603 dot 6070403 at oarcorp dot com> <20150317094510 dot GN6096 at calimero dot vinschen dot de>
On Tue, 17 Mar 2015, Corinna Vinschen wrote:
> Do we really gain anything by introducing a massive ifdef mentioning
> all targets out there? This looks like overkill.
Was there some problem with the logic I suggested in
<https://sourceware.org/ml/newlib/2014/msg00421.html> to determine the
type used for intptr_t without any per-architecture conditionals or
configure tests being needed? (It's true that if some architecture
decides to use e.g. __int24 for intptr_t, additional cases would be
needed, but that logic should cover all architectures where int, long or
long long are used.)
--
Joseph S. Myers
joseph@codesourcery.com
- References:
- Re: h8300, m32c and PRIuPTR
- Re: h8300, m32c and PRIuPTR
- Re: h8300, m32c and PRIuPTR
- Re: h8300, m32c and PRIuPTR
- Re: h8300, m32c and PRIuPTR
- Re: h8300, m32c and PRIuPTR
- Re: h8300, m32c and PRIuPTR
- Re: h8300, m32c and PRIuPTR
- Re: h8300, m32c and PRIuPTR
- Re: h8300, m32c and PRIuPTR
- Re: h8300, m32c and PRIuPTR