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 <m...@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
