This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On 3/16/2015 11:17 AM, Corinna Vinschen wrote: > On Mar 16 10:54, Joel Sherrill wrote: >> On 3/16/2015 10:08 AM, Corinna Vinschen wrote: >>> On Mar 16 09:38, Joel Sherrill wrote: >>>> I am wondering if when we avoided changing newlib-stdint.h to match the >>>> logic >>>> in glibc-stdint.h for uintptr_t by adding configure time logic, we just >>>> pushed >>>> off the problem. At this point, all I can see as a solution is something >>>> like this >>>> in inttypes.h: >>>> >>>> #if defined(__m32c__) || defined(__h8300__) >>>> /* do whatever is needed */ >>>> #else >>>> /* we can rely on the value provided by configure, use current logic */ >>>> #endif >>> Did you see my mail mentioning sys/config.h? >> This one? >>> Ideally the setting is available via compile time macros and can be used >>> to set _UINTPTR_EQ_ULONG or _UINTPTR_EQ_ULONGLONG from include/sys/config.h. >> So remove the configure.in logic and try to do the same thing dynamically >> with conditionals based on __SIZEOF_PTRDIFF__ and __SIZEOF_LONG_LONG__, >> __SIZEOF_LONG__, and __SIZEOF_INT__? >> >> This will work in some cases but with sizeof(int) == sizeof(long), >> newlib-stdint.h >> is inconsistent whether uintptr_t is "unsigned int" or "long unsigned >> int". >> And that was the more easily hit inttypes.h problem that added the logic >> to configure.in. >>> Again, the size of pointer values as well as the fact what multilib >>> we're building for should be available from gcc at compile time. This >>> information should ideally be used to influence the logic of inttypes.h >>> in sys/config.h. >>> >> Can we reliably determine long or int for uintptr_t with cpp conditionals? > Using m32c as example, if you're building for m32cm, or with flags like > -mint32, there should be builtin macros showing that. There are already > similar conditionals in sys/config.h: > > #ifdef __m32c__ > [...] > #if defined(__r8c_cpu__) || defined(__m16c_cpu__) > #define _POINTER_INT short > #else > #define _POINTER_INT long > #endif > [...] > #endif /* __m32c__ */ > > So why not set _UINTPTR_EQ_ULONG or _UINTPTR_EQ_ULONGLONG here, too, > based on a builtin macro? I have attached a test program and script that do not produce warnings for any of my test cases. And I added r8c and m16c test cases. How does that type of logic look for use in inttypes.h or to define macros in sys/config.h? I don't care about the form of the solution, only that it works. :) > > Corinna > -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherrill@OARcorp.com On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Attachment:
f.c
Description: Text document
Attachment:
j
Description: Text document
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |