octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #54299] HDF5 file I/O unit tests fail or crash


From: John W. Eaton
Subject: [Octave-bug-tracker] [bug #54299] HDF5 file I/O unit tests fail or crash Octave
Date: Fri, 13 Jul 2018 00:30:51 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0

Follow-up Comment #4, bug #54299 (project octave):

This looks like it might be a problem with the lifetime of temporary
variables?

Does the attached patch help?

I changed all instances of


octave::sys::get_ASCII_filename (ff).c_str ()


to store the result of get_ASCII_filename in a temporary variable first. 
However, it may only be the cases where you have something like


some_function (const char *name)
{
  ...
  octave::sys::get_ASCII_filename (std::string (name)).c_str ()
  ...
}


that are actually problems.  However, on Windows systems, you may be returning
a different string from the one that is passed in.  What is the lifetime of
that variable?  Does it always exist as long as the char pointer you get from
the call to c_str?

In any case, I find it clearer to have the temporary ascii_fname variable made
explicit.

Also, there are some instances of transforming the original name to the ascii
name, then using the ascii name in a stream constructor or HDF5 function and
then also using the original string in a later function.  My patch change a
couple of those, but I'm not sure I did the right thing, and I didn't do an
exhaustive check in all the functions that use get_ASCCI_filename.  We should
probably carefully check them all, and if there are places where the ascii
name AND the original name should both be used after the transformation, a
comment explaining why they are both needed should be added.

+get_ASCII_

(file #44547)
    _______________________________________________________

Additional Item Attachment:

File name: diffs.txt                      Size:9 KB


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?54299>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]