Strange problem with newlib strstr function and rtems 4.10 on coldfire

Paul Whitfield paulw at
Wed Apr 20 04:52:06 UTC 2011

On 20/04/2011 12:02 PM, Ralf Corsepius wrote:
> 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 ...
>>>> I did NOT build gcc / newlib from source.
>>>> I am using the pre-compiled version from
>>>> 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.

Wow! Ralf, I was not expect such a rapid response at all!

I was just interested in making sure it was in the
next release.

Thanks a million!

Message  protected by MailGuard: e-mail anti-virus, anti-spam and content filtering.

More information about the users mailing list