liboctave/kpse.cc

[John W. Eaton]

On 22-Jan-2011, CdeMills wrote:

| 
| While looking at warnings produced when configures with
| --enable-strict-warnings, I had a lool at kpse.cc. It seems this file came
| from kpathsea, the copyright is from 1998. It received a c++ suit, and
| various corrections have been brought over the time. But kpathsea is still
| under development, and there is a risk of divergences. Morevoer, there are a
| few c++ structs defined, not classes, with pointer data members. This means
| that there are potential problems of memory leakage and dangling pointers.
| 
| What should be do with respect to this ? The kpathsea lib is not distributed
| separatelly. It's a component of tex-live, programmed in pure C. 
| - have a kpathsea dir, like gnulib, with periodic updates from upstream, and
| have an octave-specific C++ wrapper ?
| - try to have more interactions with kpathsea maintainers ?
| - try to have better merge of modifications in upstream with the
| octave-specific kpse.cc ?

I want to eventually eliminate it completely from Octave.  I
originally used it because it did something like what I wanted (path
searching) but I think it still has too many TeX-specific things in
it.  It would be better to replace it with something that does exactly
the kind of path searching we need for Octave.

As far as I can tell, the kpse functions are not used now when
searching for function files on the path, but are only used to
implement functions like.  The only thing that the
load-path code appears to use from dir-path.h is the
dir_path::path_sep_str function.

Other than the path_sep_{str,char} functions, the only place dir_path
appears now seems to be in the following functions

  utils.cc:
    search_path_for_file
    search_path_for_all_files

  ov-fcn-handle.cc:
    octave_fcn_handle::set_fcn

  ls-mat5.cc:
    read_mat5_binary_element

It seems bad to me that these functions do not use precisely the same
method to find files on the path that the load-path functions do.

But in any case, any changes in this area will have to wait until
after branching for 3.4.

jwe