Strange problem with newlib strstr function and rtems 4.10 on coldfire
paulw at omnitronics.com.au
Mon Apr 18 08:16:22 UTC 2011
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
>> 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.
Sorry I was unclear. No I can NOT reproduce the problem on the PC.
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
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.
If I follow the same includes as in strstr.c and str-two-way.h
then SIZE_MAX is 32.
ie. If I compile the following
#if ( SIZE_MAX == 32 )
#error "SIZE MAX is 32"
With the rtems compiler (m68k-rtems4.10-gcc) I get
#error "SIZE MAX is 32" message.
If I "hack" the strstr.c/ str-two-way.h files, to force
SIZE_MAX to be UINT_MAX then the code works correctly.
My test case works.
Is something broken about how newlib has been built?
27 Sarich Court, Osborne Park
Perth WA 6017
P: +61 8 9445 2633
F: +61 8 9445 1687
I: www.omnitronics.com.au <http://www.omnitronics.com.au>
Message protected by MailGuard: e-mail anti-virus, anti-spam and content filtering.http://www.mailguard.com.au/mg
More information about the users