From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=52148 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1PgDHg-0008Nj-9O
	for qemu-devel@nongnu.org; Fri, 21 Jan 2011 04:27:57 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1PgDHe-0007SW-NH
	for qemu-devel@nongnu.org; Fri, 21 Jan 2011 04:27:56 -0500
Received: from mx1.redhat.com ([209.132.183.28]:33307)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1PgDHe-0007SN-EM
	for qemu-devel@nongnu.org; Fri, 21 Jan 2011 04:27:54 -0500
Message-ID: <4D3951F2.9040901@redhat.com>
Date: Fri, 21 Jan 2011 10:29:22 +0100
From: Kevin Wolf <kwolf@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH 1/3] make path_has_protocol() to return
	pointer instead of bool
References: <1294829822-27938-1-git-send-email-mjt@tls.msk.ru>
	<1294829822-27938-2-git-send-email-mjt@msgid.tls.msk.ru>
In-Reply-To: <1294829822-27938-2-git-send-email-mjt@msgid.tls.msk.ru>
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Michael Tokarev <mjt@tls.msk.ru>
Cc: qemu-devel@nongnu.org

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