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