Strange problem with newlib strstr function and rtems 4.10 on coldfire

[Ralf Corsepius]

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