[PATCH] Add and use __INTTYPES_EXP()

Ralf Corsepius ralf.corsepius@rtems.org
Thu Nov 22 19:49:00 GMT 2012


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.

>> 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.

Ralf



More information about the Newlib mailing list