Re: 3rd Party Nonsense (was Re: Regular Expressions?)
Re: 3rd Party Nonsense (was Re: Regular Expressions?)
- Subject: Re: 3rd Party Nonsense (was Re: Regular Expressions?)
- From: "Michael Ash" <email@hidden>
- Date: Tue, 10 Jun 2008 09:40:50 -0700
On Tue, Jun 10, 2008 at 8:20 AM, Jens Alfke <email@hidden> wrote:
>
> On 9 Jun '08, at 10:38 PM, Michael Ash wrote:
>
>> It's perfectly possible to write safe code that calls C
>> str functions. My code is no more vulnerable than the next man's. You
>> can call things like strnstr, pass the length of the NSData you're
>> working on, and there is exactly zero risk of anything.
>
> Sure, and it's perfectly possible to shave with a blade without cutting
> yourself; that doesn't mean it doesn't happen, though :/ What you're saying
> is "if you do everything right, there's zero risk of it being wrong", which
> is a tautology. The point is that people can and do make mistakes when
> working with C string APIs (even the "n" ones).
This is true but meaningless. People can and do make mistakes with
*everything*. The C string APIs don't have a particularly special
place as far as security vulnerabilities go.
>> No, it's not. A common technique is to use C string APIs to find line
>> endings, then try the full line as UTF-8. If it fails, then you can
>> fall back on a more forgiving encoding.
>
> Yes, I do try UTF-8 first. Sorry, I was being brief in the previous message,
> describing only the _fallback_ if UTF-8 parsing fails.
>
> I'm not sure why you would want to use C APIs to look for line endings
> first, though?
When working with streaming data then you need to find a delimiter to
safely cut the stream before trying UTF-8, because if the end of your
chunk of data ends in the middle of a UTF-8 code word (or whatever
it's called), then the result will be invalid UTF-8 even if the stream
as a whole is valid UTF-8. You could write a UTF-8 parser to find good
cut points, but it's much easier when working with a line-oriented
protocol to just look for CRLF.
Mike
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden