[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/