[PATCH] Add and use __INTTYPES_EXP()

[Sebastian Huber]

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

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. 
  For example the format specifier for PRIuMAX was wrong.

I use now stdint.h from Newlib and this works.

-- 
Sebastian Huber, embedded brains GmbH

Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
Phone   : +49 89 18 90 80 79-6
Fax     : +49 89 18 90 80 79-9
E-Mail  : sebastian.huber@embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.