[FFmpeg-devel] [PATCH] url_split() ipv6 support

[Ronald S. Bultje]

Hi Michael,

On 9/27/07, Michael Niedermayer <michaelni at gmx.at> wrote:
>
> url_split() looks messy, maybe we should clean it up first, maybe
> something
> like:
>
> char tmp[256];
> int count;
> proto[0] = auth[0]= 0;
> if(sscanf(p, "%255[^:]:%*[:/]%n", &tmp, &count) == 2){
>     av_strlcpy(proto, tmp, proto_size);
>     p+= count;
> }
> if(sscanf(p, "%255[^@/]@%n", &tmp, &count) == 2){
>     av_strlcpy(auth, tmp, auth_size);
>     p+= count;
> }
>
>
> could be used?


It is messy, I agree, however, sscanf() isn't good for a few reasons (may or
may not be important):
- relatively unreadable compared to strchr(), but same LOC
- (probably?) slower than strchr()
- sscanf() should probably directly write into the buffer instead of into a
tmp

I took a slightly different approach of using strchr() in different order
(first separate proto, then path, then parse the hostname and auth/port info
in it), it looks pretty good (=simple/readable), see attached. It doesn't
parse ipv6 urls yet, to separate the rewrite from the new functionality. I
hope this is more to your taste, then I'll add ipv6 to this one.

The patch exposes a (API) problem in av_strlcpy(), where I can't (API-wise)
straightforwardly copy only n characters (like strncpy()), because
av_strlcpy(proto, "http://bla", 4); only copies 3 chars (4th being the
'\0'). I have to add +1 to each av_strlcpy() to actually copy all characters
up to the non-\0-endpoint into the target buffer. Maybe we need a
av_strlncpy() to make this API more fluffy?

Ronald
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ffmpeg-url_split-simplify.patch
Type: application/octet-stream
Size: 3370 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070927/05b36183/attachment.obj>