Quick and dirty malloc() support for realpath.

[Rob Landley]

On Tuesday 27 October 2009 05:51:05 Bernhard Reutner-Fischer wrote:
> On Tue, Oct 27, 2009 at 08:54:50AM +0100, Ricard Wanderlof wrote:
> >On Mon, 26 Oct 2009, Rob Landley wrote:
> >>... Also, in my experience _Bool is about as real-world useful as
> >>the bit field notation with the colons, and is really there to keep
> >>the language pedants and the c++ guys happy without actually
> >>accomplishing much.  I've never seen it actually produce better
> >>code.
> >
> >It can produce more readable, less error-prone C code though. We use
>
> $ size libc/stdlib/realpath.o*
>    text	   data	    bss	    dec	    hex	filename
>     555	      0	      0	    555	    22b	libc/stdlib/realpath.os.oorig
>     735	      0	      0	    735	    2df	libc/stdlib/realpath.os.rob
>     586	      0	      0	    586	    24a	libc/stdlib/realpath.os
>
> perhaps that would do as well and doesn't cost 180b (!) but about 31b..

The problem is that leaks memory if realpath ever returns failure, such as the 
lines right after that patch:

        path_len = strlen(path);
        if (path_len >= PATH_MAX - 2) {
                __set_errno(ENAMETOOLONG);
                return NULL;
        }

And at least a half-dozen other "return NULL;" error cases later in the 
function.

Possibly there's some way to not inline the alloca?  This was, as I said, a 
quick and dirty fix.  Someday we should properly make it handle more than 
PATH_MAX, but that's a big change and I'm just trying to get software using 
Linux libc extensions (and now SUSv4) to work.

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds