Brandon Williams <bmwill@xxxxxxxxxx> writes:
> Create real_pathdup which returns a caller owned string of the resolved
> realpath based on the provide path.
>
> Signed-off-by: Brandon Williams <bmwill@xxxxxxxxxx>
> ---
> abspath.c | 13 +++++++++++++
> cache.h | 1 +
> 2 files changed, 14 insertions(+)
>
> diff --git a/abspath.c b/abspath.c
> index 8c6c76b..79ee310 100644
> --- a/abspath.c
> +++ b/abspath.c
> @@ -205,6 +205,19 @@ const char *real_path_if_valid(const char *path)
> return strbuf_realpath(&realpath, path, 0);
> }
>
> +char *real_pathdup(const char *path)
> +{
> + struct strbuf realpath = STRBUF_INIT;
> + char *retval = NULL;
> +
> + if (strbuf_realpath(&realpath, path, 0))
> + retval = strbuf_detach(&realpath, NULL);
> +
> + strbuf_release(&realpath);
> +
> + return retval;
> +}
OK. Taken alone, the above makes a reader wonder if it still makes
sense for strbuf_realpath() to return realpath.buf (or NULL upon
error). An obvious alternative is to return 0 on success and -1 on
failure.
But other callers of strbuf_realpath() are mimicking the historical
"give a path in 'const char *', receive a path in 'const char *'
that you have to xstrdup() if you want to keep it" interface, and
this interface may be easier for them. I dunno.
> /*
> * Use this to get an absolute path from a relative one. If you want
> * to resolve links, you should use real_path.
> diff --git a/cache.h b/cache.h
> index 7a81294..e12a5d9 100644
> --- a/cache.h
> +++ b/cache.h
> @@ -1068,6 +1068,7 @@ char *strbuf_realpath(struct strbuf *resolved, const char *path,
> int die_on_error);
> const char *real_path(const char *path);
> const char *real_path_if_valid(const char *path);
> +char *real_pathdup(const char *path);
> const char *absolute_path(const char *path);
> const char *remove_leading_path(const char *in, const char *prefix);
> const char *relative_path(const char *in, const char *prefix, struct strbuf *sb);