On 17.07.2002 06:04:20 bug-gnustep-admin wrote:
> Roland Schwingel wrote:
> >
> > Hi...
> >
> > I assume a bug in NSString.m method:
> > - (void) getLineStart: (unsigned *)startIndex end: (unsigned
> > *)lineEndIndex contentsEnd: (unsigned *)contentsEndIndex forRange:
> > (NSRange)aRange
> >
> > When you read the code carefully you will find this (about line 1852 in
> > gnustep-base-1.1.0):
> > ...
> > if (lineEndIndex)
> > {
> > if (end < len
> > && ((*caiImp)(self, caiSel, end) == (unichar)0x000D)
> > && ((*caiImp)(self, caiSel, end+1) == (unichar)0x000A))
> > {
> > *lineEndIndex = end+1;
> > }
> > else
> > {
> > *lineEndIndex = end;
> > }
> > }
> > ...
> >
> > When one will assume that end and len are just one number away
> > (eg end==101 and len==102 ) - what can happen when you read the whole
> > method - the
> > ((*caiImp)(self, caiSel, end+1) == (unichar)0x000A) in the second if()
> > statement
> > will fail with a Rangeexception in GSStrings characterAtIndex_c()
> > because you read
> > one letter out of range...
> >
> > If this is true maybe this should be fixed...
> >
> > Roland
> >
> > PS: This is my first posting to this list I hope I am right here...
>
> Yes you are. Although since the compiler tends to optimize away the
> second check if the first one is false, it only gets triggered in rare
> circumstances (well on Windows, perhaps not so rare) with two \r at the
> end of the string, such as:
>
> s = @"This is a line of text\r\r";
>
> Thanks for pointing this out.
I did some tests and indeed it breaks on windows
eg. on files ending like this (read as bytes in hex)
(od -x output on cygwin)
3939 0d39 0d0d 000d