Re: [PATCH] Add and use __INTTYPES_EXP()

[Ralf Corsepius <ralf dot corsepius at rtems dot org>]

On 11/22/2012 12:15 PM, Sebastian Huber wrote:
> On 11/22/2012 11:54 AM, Ralf Corsepius wrote:
> > On 11/22/2012 11:40 AM, Sebastian Huber wrote:
> > > On 11/22/2012 11:27 AM, Ralf Corsepius wrote:
> > > > On 11/22/2012 10:37 AM, Sebastian Huber wrote:
> > > >
> > > > > introduces __STDINT_EXP() in inttypes.h.  If we use the GCC provided
> > > > > stdint.h, then this results in:
> > > > >
> > > > > inttypes.h:245:32: error: missing binary operator before token "("
> > > > > inttypes.h:248:34: error: missing binary operator before token "("
> > > >
> > > > reproducer?
> > >
> > > I tried to use the current Newlib HEAD.
> > >
> > > > RTEMS has been using the GCC provided stdint.h combined with a
> > > > different patch
> > > > to newlib's inttypes.h applied[1] with none such error having been
> > > > reported by
> > > > anybody anywhere.
> > > >
> > > >
> > > > That said, as this patch has not seen wider exposure to the public,
> > > > this patch
> > > > is too intruse to allow it letting it into newlib without further
> > > > _extensive_
> > > > testing in and outside of RTEMS.
> > Note: I did not say your patch is wrong. I only said it needs more
> > testing (==
> > time).
> > As far as I am concerned, this at least means me to rebuild all RTEMS
> > toolchains with your patch applied, to rebuild all of RTEMS with the
> > resulting
> > toolchains and to compare the results of the different versions of the
> > toolchains with my inttypes/stdint-testsuite.
> >
> > This means several weeks of (spare-time) work for me.
>
> Ok.  I hit this problem since I try now to tackle the fseek() issue:
>
> http://sourceware.org/ml/newlib/2012/msg00214.html

You have my work-around (I recall having sent it to you on PM).

> For this I switched to Newlib HEAD.
>
> > > > Ralf
> > > >
> > > > [1] These patches were not submitted because they are hacks and
> > > > because there
> > > > are other issues inside of newlib when being used with GCC's stdint.h.
> > >
> > > Ok, this means that current Newlib + GCC provided stdint.h is broken
> > > at the
> > > moment?
> > Correct. Most critical issue is newlib's stdint.h is conflicting with
> > the GCC
> > generated one during bootstrapping the GCC/newlib.
> >
> > ATM, the only known work-around to this issue is to physically remove
> > newlib's
> > stdint.h from the source-tree, before building (So far, this has been
> > scripted
> > in my buildscripts (the rpm.specs) and will likely do so in the next
> > generation
> > of the rtems-newlib-patches).
> >
> > I already was inclined to propose to let newlib drop providing
> > stdint.h and to
> > change all newlib based GCC's to use the GCC-provided stdint.h, but I
> > don't
> > think this proposal would have any chance to be accepted.
> > Unfortunately, I
> > haven't found a better solution, yet.
>
> 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.

Ralf