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]

Re: [PATCH] Add and use __INTTYPES_EXP()


On Nov 26 17:01, Ralf Corsepius wrote:
> On 11/23/2012 10:41 AM, Corinna Vinschen wrote:
> >On Nov 22 12:36, Ralf Corsepius wrote:
> >>On 11/22/2012 12:15 PM, Sebastian Huber wrote:
> >>>I deleted stdint.h from Newlib, but there seem to be more issues in
> >>>inttypes.h.
> >>
> >>Yes. Like I said, RTEMS has a different patch to inttypes.h, which
> >>is supposed to exactly address these issues.
> >>
> >>>For example the format specifier for PRIuMAX was wrong.
> >>Which particular case (target/multilib)?
> >>
> >>I can check my testsuite with the current rtems toolchain rpms.
> >>
> >>>I use now stdint.h from Newlib and this works.
> >>This would surprise me, because I know, newlib's inttypes.h/stdint.h
> >>are broken.
> >
> >Nice discussion, but would anybody of you let the rest of us in on
> >the secret of newlib's stdint.h/intttypes.h brokenness?
> 
> It's been a while since I checked the last time, when I had switched
> RTEMS to use GCC's stdint.h. I'll try to check whether the current
> status in vanilla newlib still has issues. Unfortunately I currently
> don't have sufficient time available, so this will take time.
> 
> One major issue had been, newlib's stdint.h/inttypes.h types based
> on guesses base on ordinal types' _sizes_, while GCC internally is
> expecting certain _types_ in certain GCC internal
> operrations/checks.
> 
> For example, GCC was issuing warnings for certain types of arguments
> to fprintf, even through the sizes of a stdint-type matches the
> expectations.
> 
> AFAIR, the cause for this, was for example newlib's stdint.h setting
> "int32_t" to "long", while GCC was expecting "int" (with sizeof(int)
> == sizeof(long) == 32bit) ... and vice versa on other
> targets/multilibs.

That's still the case in HEAD because the test for __have_long32
preceeds the test for INT_MAX.

That's kind of funny, considering that you contributed the file
originally :)  


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]