Re: [Qemu-devel] [PATCH 1/3] make path_has_protocol() to return pointer instead of bool

[Kevin Wolf <kwolf@redhat.com>]

Am 12.01.2011 11:57, schrieb Michael Tokarev:
> Currently protocol: parsing in filenames is ad-hoc and scattered all around
> block.c.  This is a first step to prepare for common parsing.
> 
> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
> ---
>  block.c |   18 +++++++++++++++---
>  1 files changed, 15 insertions(+), 3 deletions(-)
> 
> diff --git a/block.c b/block.c
> index ff2795b..e5a6f60 100644
> --- a/block.c
> +++ b/block.c
> @@ -90,9 +90,11 @@ int is_windows_drive(const char *filename)
>  }
>  #endif
>  
> -/* check if the path starts with "<protocol>:" */
> -static int path_has_protocol(const char *path)
> +/* check if the path starts with "<protocol>:"
> + * Return pointer to the leading colon or NULL */
> +static char *path_has_protocol(const char *path)
>  {
> +    const char *p;
>  #ifdef _WIN32
>      if (is_windows_drive(path) ||
>          is_windows_drive_prefix(path)) {
> @@ -100,7 +102,17 @@ static int path_has_protocol(const char *path)
>      }
>  #endif
>  
> -    return strchr(path, ':') != NULL;
> +    p = path;
> +    /* we allow [a-z_] for now */
> +    while((*p >= 'a' && *p <= 'z') || *p == '_') {

Maybe qemu_isalnum(*p)  || *p == '_' instead? We probably won't need
uppercase letters, but digits are well possible.

We'll have a hard time adding any characters here later as this will
break previously working image filenames.

> +        ++p;
> +    }
> +
> +#define MAX_PROTO_LEN 31
> +    /* recognize non-empty string of max MAX_PROTO chars as protocol */
> +    return
> +        *p == ':' && p > path && (p - path) <= MAX_PROTO_LEN ?
> +            (char*)p : NULL;

What's the point of MAX_PROTO_LEN? It just seems to make the handling
even less consistent than it already is.

Kevin