Re: CFFTPCreateParsedResourceListing bug
Re: CFFTPCreateParsedResourceListing bug
- Subject: Re: CFFTPCreateParsedResourceListing bug
- From: Frederick Cheung <email@hidden>
- Date: Thu, 19 May 2005 18:50:29 +0100
On 19 May 2005, at 18:39, Daniel Jalkut wrote:
I didn't realize the CFNetwork stuff had gotten into darwin! Cool!
When did this happen? (wakes up from long daze, apparently).
With tiger it would seem.
Fred
On May 19, 2005, at 7:07 AM, Frederick Cheung wrote:
I believe there is a bug in CFFTPCreateParsedResourceListing.
My app has the following behaviour: I read bytes in from a stream
(not a cfftpstream, I am rolling my own ftp layer), stick them in
a CFMutableDataRef. I call CFFTPCreateParsedResourceListing as
much as I can. When it returns 0, i stash the leftover bytes in a
safe place. The next time I get some bytes to processed, these are
appended to the left over bytes.
If the buffer ends with \r\n then CFFTPCreateParsedResourceListing
seems to indicate that it has consumed all bytes apart from the
trailing \n, so next time round my buffer starts with a \n.
This causes CFFTPCreateParsedResourceListing to return 0, since
the source reveals that when it encoutners a blank line.
The offending passage seems to be (http://www.opensource.apple.com/
darwinsource/10.4.1/CFNetwork-128/FTP/CFFTPStream.c)
if (ret && ((ret < newline) || !newline)) {
eol = newline = ret;
while (newline < (last - 1)) {
if ((*newline == '\r') || (*newline == '\n'))
newline++;
else {
newline--;
break;
}
}
}
When the \n character is the last character in the buffer, newline
is not touched, so is left pointer at the penultimate character
(ie the \r of the \r\n pair). Since the number of bytes parsed is
calculated as the number of bytes upto and including the newline
character, this means that it counts the last character as not
being consumed, even though it has been.
This is easy enough to work around, if I find myself with one byte
left, i can just check if it is the \n part of a trailing \r\n
pair, and if so pretend it was also consumed. Also is it really
appropriate for CFFTPCreateParsedResourceListing to return 0 (ie
there aren;t enough bytes when in fact there are loads of them).
Would it not be preferable to consume skip the offending line
(possibly returning an empty parseResult dictionary) ?
I'll write up a radar when I have the time, but if anyone wonders
why they are missing files/folders when using
CFFTPCreateParsedResourceListing, I believe this why
Fred
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
sweater.com
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden