Re: [PATCH 4/5] strbuf_readlink(): support link targets that exceed PATH_MAX

From: Patrick Steinhardt <ps@pks.im>
Date: Dec 17, 2025, 14:44 UTC
Message-ID: <aULB3wCFGsbZbuSw@pks.im>
In-Reply-To: <db1feb2293d20532f9468ab63ede43d4fc620203.1765899229.git.gitgitgadget@gmail.com>

On Tue, Dec 16, 2025 at 03:33:48PM +0000, Karsten Blees via GitGitGadget wrote:

Show 22 quoted lines

> diff --git a/strbuf.c b/strbuf.c
> index 44a8f6a554..fa4e30f112 100644
> --- a/strbuf.c
> +++ b/strbuf.c
> @@ -566,8 +566,6 @@ ssize_t strbuf_write(struct strbuf *sb, FILE *f)
>  	return sb->len ? fwrite(sb->buf, 1, sb->len, f) : 0;
>  }
>  
> -#define STRBUF_MAXLINK (2*PATH_MAX)
> -
>  int strbuf_readlink(struct strbuf *sb, const char *path, size_t hint)
>  {
>  	size_t oldalloc = sb->alloc;
> @@ -575,7 +573,7 @@ int strbuf_readlink(struct strbuf *sb, const char *path, size_t hint)
>  	if (hint < 32)
>  		hint = 32;
>  
> -	while (hint < STRBUF_MAXLINK) {
> +	for (;;) {
>  		ssize_t len;
>  
>  		strbuf_grow(sb, hint + 1);

This makes me wonder whether we have a better way to figure out the actual size of the buffer that we ultimately need to allocate. But reading through readlink(3p) doesn't indicate anything, and I'm not sure whether we can always rely on lstat(3p) to return the correct size for symlink contents on all platforms.

One thing that _is_ noted though is that calling the function with a buffer size larger than SSIZE_MAX is implementation-defined. It does make me a bit uneasy in that light to grow indefinitely.

Which makes me wonder whether Windows has a limit for the symlink contents that we could enforce in theory so that we can reasonably turn this into a bounded loop again?

Patrick