Re: [musl] realpath without procfs -- should be ready for inclusion

[Rich Felker <dalias@libc.org>]

On Tue, Nov 24, 2020 at 09:35:55AM -0500, Rich Felker wrote:
> On Tue, Nov 24, 2020 at 12:21:36PM +0300, Alexey Izbyshev wrote:
> > On 2020-11-24 09:30, Rich Felker wrote:
> > >I think before this goes upstream we should have a good set of
> > >testcases that can be contributed to libc-test. Do you have ideas for
> > >coverage? Some that come to mind:
> > >
> > Added some more ideas.
> > 
> > [...]
> > - An argument ending with an absolute symlink with the target having
> > length PATH_MAX-1 (valid path)
> > 
> > Hm, the last one doesn't work now. Since p is the position of NUL
> > instead of the size of stack, "if (k==p) goto toolong;" forbids
> > symlinks with the length of the target == PATH_MAX-1.
> 
> This should be fixable just by increasing size of stack to PATH_MAX+1.
> In theory it doesn't need to be null-terminated but then strchrnul
> won't work. memchr would work instead but it's slightly less
> convenient to use.

One thing I noticed while working out test ideas: my very early
observation that we can use the caller's buffer for output is wrong.
The spec allows it to have been clobbered on failure but not on
success; there's nothing allowing write past the resulting string
size.

It's not too bad to have two 4k buffers, but I think we can actually
put them together. PATH_MAX+1 isn't quite enough because, when
expanding a link, we momentatily need space for both the link name and
contents. However PATH_MAX+NAME_MAX+2 should suffice, since at most
a NAME_MAX part is being removed before pushing the link contents onto
the stack. I don't really feel like making this improvement now
though; it's better done as a change later if desired.

Rich