Riccardo Mottola wrote: > It is interesting that I get this bug only in this file and not for every > file. I suppose it has to be termination dependent and usually exists before.
I'd expect it depends on whether you source file ends immediately after the last token or whether there is a newline character (or any other white space) after it. > anyway, changing the range to > > for (i = 1; i < _length; i++) > > breaks the parser: I don't get any crashes, but it doesn't parse any methods > in any file! using <= makes it work, but it will of course still crash (and > crashes). Thus the code expects to be able to peek "one after". Okay, upon a second inspection the original termination condition i < _length + 1 may be right, but in that case the assignment endType = codeType(_uchar+end) is wrong. In fact, you do not need this assignment and the local variable endType at all. Instead the condition in the if statement should be corrected. Change if ((startType != endType) || (end == _length)) into if (end == _length || startType != codeType(_uchar+end)) so that the array access is made only within the bounds of the buffer. Wolfgang _______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
