[PATCH] Add and use __INTTYPES_EXP()

[Ralf Corsepius]

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