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

[Carmelo AMOROSO]

Denys Vlasenko wrote:
> 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
>   

Hi Denys,
I'm just now playing with uclibc-trunk (linuxthreads.old implementation) 
and discovered
that your latest change on realpath implementation brakes test-canon 
test from uclibc test-suite.
Indeed, I've run exactly the same on nptl branch (that contains the 
previous implementation of
the realpath function) and it works fine.

Have you run these tests before committing the patch... yes, likely 
nodoby reviewed your patch,
but for sure something now doesn't work longer.

Thanks,
Carmelo
> ------------------------------------------------------------------------
>
> _______________________________________________
> uClibc mailing list
> uClibc at uclibc.org
> http://busybox.net/cgi-bin/mailman/listinfo/uclibc