fix memory leaks in prefix.c.

Zack Weinberg zack@wolery.cumb.org
Tue Mar 14 10:30:00 GMT 2000


On Tue, Mar 14, 2000 at 10:52:42AM -0700, Jeffrey A Law wrote:
> http://www.cygnus.com		http://www.cygnus.com/egcs
> 
>   In message < 20000312093621.B15697@wolery.cumb.org >you write:
>   > This patch cleans up prefix.c.  The main purpose is to fix the memory
>   > leaks.  update_path() is now guaranteed to return a malloced copy of
>   > the string you passed in, possibly modified.  Before, there was no way
>   > to tell if it had copied the string or not.  All the internal leaks
>   > are also removed.  There's one exception - get_key_value will leak on
>   > Win32 hosts, because the result of the registry lookup is in malloced
>   > memory, but the result of getenv isn't.  I see no good way around this.
>   > 
>   > I also moved cpplib's simplify_path() function into prefix.c, and
>   > caused update_path not to dink with the directory separators.
>   > Instead, you can call simplify_path on the result if you want.
>   > 
>   > I haven't tested this in a context where update_path is actually
>   > expected to change pathnames.  It does, however, complete a bootstrap
>   > successfully in the normal environment.
> Can you please test it in such an environment?  We're having a lot of
> stability problems right now and I'd like to have folks slow down a little
> and perform more complete testing of patches to try and stabilize the tree.

I'm not clear on what that environment would be.  I did some trivial
tests (setting GCC_ROOT, -V and -b to point to the system compiler,
which is 2.95.2) and that appears to do the right thing.

>   > Why isn't prefix.c part of libiberty?
> Historical.  GCC did not use libiberty until a year or two ago -- a goodly
> amount of work has been done by various people to remove duplicate functions
> between GCC and libiberty and push generic library code into libiberty so 
> that other project can use it.
> 
> I've got no objections to moving prefix.c into libiberty.

Shall I send a patch to do that, and then revise the memory-leaks
patch, or would you prefer to get the memory-leaks patch nailed down
first?

zw



More information about the Gcc-patches mailing list