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

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

[Octave-bug-tracker] [bug #49118] GUI editor cannot run file in folder n


From: Mike Miller
Subject: [Octave-bug-tracker] [bug #49118] GUI editor cannot run file in folder name with umlaut
Date: Sat, 17 Dec 2016 20:35:25 -0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:49.0) Gecko/20100101 Firefox/49.0

Follow-up Comment #38, bug #49118 (project octave):

Retagging to 4.2.0 release.

I had a look at the patch, and even though I can't test or build with this, I
suppose if this is the only way to get wide character file name support in
Windows this is a reasonable approach. I think it might be cleaner if we could
more clearly define the layer between the type that Octave uses for strings
(now a std::string, but in the future it may become a std::wstring) from what
the OS (or other libraries) expect to be given to represent the name of a
file/directory/resource.

I don't think you need to add new wrapper functions for these Windows library
calls in the liboctave/wrappers directory. The purpose of that directory is to
encapsulate the workarounds between glibc and gnulib into a small C API that
Octave's C++ libraries can use unconditionally. If you're going to make the
code elsewhere dependent on whether it's Windows or not, and whether the
function takes a char or a wchar_t, then you might as well just call the
Windows function directly. For exmaple, instead of defining a new function
octave_wmkdir_wrapper, just use an #if in place and call _wmkdir directly.

It would be nice if the workarounds that have to be done for HDF5 could be
abstracted away a little more so the load-save.cc module doesn't have to know
details about which OS it is running on, just about how to get a safe file
name from an Octave string type.

Same thing with the parser, maybe we can add an fopen wrapper to
liboctave/system/file-ops.cc to encapsulate calling either std::fopen or
_wfopen.

Definitely avoid putting conditionals into public header files, the
OCTAVE_USE_WINDOWS_API can't be put into the file-ops.h header file.

    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

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