Subject: Re: [PATCH] http-push: refactor request url creation

From: Junio C Hamano <[email-masked]>
Date: Sun, 25 Jan 2009 12:35:04 -0800

Ray Chuan <[email-masked]> writes:

> Currently, functions that deal with objects on the remote repository
> have to allocate and do strcpys to generate the URL.
>
> This patch saves them this trouble, by providing a function that
> returns a URL: either the object's 2-digit hex directory (eg.
> /objects/a1/) or the complete object location (eg. /objects/a1/b2).
>
> Acked-by: Johannes Schindelin <[email-masked]>
> Signed-off-by: Tay Ray Chuan <[email-masked]>

If you wrote it, and then Johannes vetted it, then these two should be in
the opposite order.

> +static char *get_remote_object_url(const char *url, const char *hex,
> int only_two_digit_prefix) {

Linewrapped.

> +	struct strbuf buf = STRBUF_INIT;
> +
> +	strbuf_addf(&buf, "%sobjects/%.*s/", url, 2, hex);
> +	if(!only_two_digit_prefix)

"if (..."

> @@ -304,17 +312,7 @@ static void start_fetch_loose(struct
> transfer_request *request)
>
>  	git_SHA1_Init(&request->c);
>
> -	url = xmalloc(strlen(remote->url) + 50);
> ...
> -	strcpy(request->url, url);
> +	request->url = get_remote_object_url(remote->url, hex, 0);
> ...
> -	curl_easy_setopt(slot->curl, CURLOPT_URL, url);
> +	curl_easy_setopt(slot->curl, CURLOPT_URL, request->url);

The original code gave a separate "url" to setop() but this gives the same
string.  Does curl_easy_setop() copies the given string away?  IOW is this
change safe?

> @@ -550,21 +540,11 @@ static void start_put(struct transfer_request *request)
>
>  	request->buffer.buf.len = stream.total_out;
>
> -	request->url = xmalloc(strlen(remote->url) +
> ...
> -	strcpy(posn, request->lock->token);
> +	strbuf_addf(&url_buf, "Destination: %s",
> get_remote_object_url(remote->url, hex, 0));

Linewrapped.

The return value from get_remote_object_url() leaks here.

> +	request->dest = strbuf_detach(&url_buf, NULL);
> +
> +	strbuf_addf(&url_buf, "%s_%s", get_remote_object_url(remote->url,
> hex, 0), request->lock->token);

The return value from get_remote_object_url() leaks here, too.