Re: fix memory leaks in prefix.c.

[Jeffrey A Law <law at cygnus dot com>]

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.

Or at least perform some crude tests by passing in strings that need 
translation and verify that the translated string you get back looks
reasonable.

  > 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.



jeff