Strange problem with newlib strstr function and rtems 4.10 on coldfire

[Ralf Corsepius]

On 04/20/2011 03:13 AM, Paul Whitfield wrote:
> On 18/04/2011 5:21 PM, Ralf Corsepius wrote:
>> On 04/18/2011 10:16 AM, Paul Whitfield wrote:
>>> On 18/04/2011 2:53 PM, Ralf Corsepius wrote:
>>>> On 04/18/2011 06:28 AM, Paul Whitfield wrote:
>>>>> On 18/04/2011 10:51 AM, Paul Whitfield wrote:
>>>>
>>>>> I have checked the newlib CVS and the version of strstr.c and
>>>>> str-two-way.h in RTEMS4-10 are update to date with the most current
>>>>> version.
>>>>>
>>>>> One last note: Recompiling the strstr.c / str-two-way.h code newlib
>>>>> code
>>>>> on the PC the code works correctly with the optimised version.
>>>>
>>>> Are you trying to express you can reproduce your issue on PC?
>>>>
>>>> I just tried, but I can't reproduce it.
>>>>
>>>> Ralf
>>>
>>> Sorry I was unclear. No I can NOT reproduce the problem on the PC.
>> OK.
>>
>>> I have done some more investigation ...
>>>
>>> PLEASE NOTE:
>>> I did NOT build gcc / newlib from source.
>>>
>>> I am using the pre-compiled version from
>>> ftp://ftp.rtems.org//pub/rtems/mingw32/4.10/
>>> and it is behaving the same way as the code I am compiling here.
>>>
>>> I did some searching and found a similar symptom to what I have
>>> been seeing.
>>>
>>> It seems to be the strstr code is breaking because it expects the value
>>> of the macro SIZE_MAX to be the maximum value of a size_t variable
>>> however it appears that using the standard RTEMS include files,
>>> SIZE_MAX is actually 32.
>>>
>> You are right on the spot. SIZE_MAX is wrong.
>>
>>> Is something broken about how newlib has been built?
>> Not quite.
>>
>> It's a bug in our stdint.h which gets exposed when using newlib with
>> gcc-4.4.x. It does not get exposed with newer gccs (e.g. rtems4.11),
>> because the preprocessor takes a different path, then.
>>
>> I'll further investigate and try to come up with a fix. - I recall us
>> having had this issue before and thought I had fixed it. Apparently
>> not ;)
>>
>> Ralf
>
> Hi Ralf / All,
>
> Would it be helpful if I raised a bug report for this ?

Patience, please, ... an "emergency bug fix", which hopefully resolves 
this issue, is on its way, but building the toolchains takes time.

The patch already is in CVS, most Linux packages already have been 
updated[1] and the mingw/cygwin toolchains are building.

If things work out as desired, the mingw32 packages will land within the 
next couple of hours.

Ralf

[1] All distros but Fedora 15 - The Fedora 15 builts failed for reasons 
still to be investigated, but unrelated to this issue.