[PATCH] realpath stack usage 8k -> 4k

[Denys Vlasenko]

On Sunday 02 December 2007 02:44, Denys Vlasenko wrote:
> Proposed patch uses user-supplied buffer directly,
> without intermediate on-stack copy.
> This can only make a difference if user supplied
> a buffer which is too small - thus user breaks API.
>
> Failure scenario:
>
> realpath("/link_name", user_buffer)
>
> /link_name -> /very_long_name_which_fits_into_PATH_MAX_and_is_also_a_link
> -> -> /shorter_name
>
> If user will give e.g. 40-char user_buffer, current implementation
> will work, patched one will overflow user_buffer by intermediate name.
>
> This should not be a problem - user must supply PATH_MAX sized buffer,
> and in this case patched version also works correctly.

And the following patch on top of previous one reuses copy_buf[]
for readlink, eliminating link_buf[]. In order to make it work,
"source" pathname is kept at the end of copy_buf, not at the
beginning (so that last NUL byte is the last byte of the copy_buf[]).

The situation when readlink returns link name which is too long
(so that it overwrites pathname), was resulting in ENAMETOOLONG
error return. This patch does the same - the fact the we now trash
pathname does not matter, as we are not returning it to the user.

Run tested.

Can somebody review these patches please?
--
vda
-------------- next part --------------
A non-text attachment was scrubbed...
Name: realpath2.diff
Type: text/x-diff
Size: 2455 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/uclibc/attachments/20071202/c432096d/attachment-0002.bin