This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Eric Blake wrote:Patch works for x86-linux and is checked in. I don't have an arm system to play around with. Sam, are you running arm-linux (which isn't in newlib)? That would use the code in question. Otherwise, can you provide more details (e.g. run under gdb and print out the various information above)?Jeff Johnston <jjohnstn <at> redhat.com> writes:Ok, I got mixed up on what SIZE_MAX was supposed to be. For x86, stdint.h is being overridden with one in libc/sys/linux/include that has a wrong value for SIZE_MAX (LONG_MAX). I am rebuilding now. I can't say what is happening for arm since it should be using the same stdint.h from libc/include.
max_suffix = SIZE_MAX; j = 0; k = p = 1; while (j + k < needle_len) { a = CANON_ELEMENT (needle[j + k]); b = CANON_ELEMENT (needle[max_suffix + k]);
it is the line b=....
It cannot be correct as you are trying to reference SIZE_MAX + 1 the first time through the loop.
But the comments state:
/* Invariants:
0 <= j < NEEDLE_LEN - 1
-1 <= max_suffix{,_rev} < j (treating SIZE_MAX as if it were signed)
...
On cygwin, this works (in other words, I'm not reproducing the crash). The intent is that this line is referencing needle[0]. What type is size_t on your platform, and the value of SIZE_MAX? Could it be that there is some type promotion going on, where the result of SIZE_MAX+1 results in a 64-bit type containing 2**32 instead of 0, as is required by modulo math since size_t is unsigned?
-- Jeff J.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |