Cutter: Can't open file with utf8 chars in name

[xarkes]

I have been reported that files containing utf8 characters in their name cannot be loaded in Cutter (Windows).
I tried it with master on Linux and it works, although there are some issues:

[pelijah]

What do you mean under "cannot be loaded in Cutter"? Does it crash?

[xarkes]

It says "File not found" or similar error.

[pelijah]

Hmm my Cutter can open files with names that contains Unicode characters.

[xarkes]

cc @XVilka
Amyway I think there's the display info that is still wrong in the Dashboard

[ITAYC0HEN]

Verified on Windows 64bit release:

[a1ext]

will try to fix it

[ITAYC0HEN]

Great! Thank you :)

[xarkes]

What's your status on it @a1ext ?

[a1ext]

Hi @xarkes, I'm trying to deal with this problem from different sides.

The goal is to supply an ANSI encoded multi-byte string to an open function (it is being called when you call r_core_file_open -> r_sandbox_open -> open). This API is deprecated in MSVC 2017 (!!!).

(Tried to rename open with _open, but unfortunatelly this didn't work.)

I can explain my trials:

1. get the System text codec, encode every path which goes to r2 API call with this codec:

bool CutterCore::loadFile(QString path, ut64 baddr, ut64 mapaddr, int perms, int va,
                          bool loadbin, const QString &forceBinPlugin)
{
    CORE_LOCK();
    RCoreFile *f;
    r_config_set_i(core_->config, "io.va", va);

    const QByteArray &baPath = qhelpers::nativeFromString(QDir::toNativeSeparators(path)); // << this guy

    f = r_core_file_open(core_, baPath.constData(), perms, mapaddr);
    if (!f) {
        eprintf("r_core_file_open failed\n");
        return false;
    }

where qhelpers::nativeFromString is:

namespace {

constexpr char kSystemLocaleName[] = "System";

}

QByteArray nativeFromString(const QString &s)
{
    return QTextCodec::codecForName(kSystemLocaleName)->fromUnicode(s);
}

QString stringFromNative(const QByteArray &ba)
{
    return QTextCodec::codecForName(kSystemLocaleName)->toUnicode(ba);
}

This means we put already encoded multi-byte string to r2. This works, but this is not conforms that r2 expects every string is passed is being encoded in utf8, so some of points in cutter have to be additionally fixed, like the following:

I don't like this solution at all

1. Set utf-8 locale at the app start and leave everything as is.

#ifdef Q_OS_WIN
    char* setloc_rv = std::setlocale(LC_ALL, "en_US.utf8");
    qDebug() << "CutterApplication(): setlocale() = " << (setloc_rv ? setloc_rv : "failed");

Expected to work, but as I've seen during testing, its behavior is unstable, below are the fail table:

| OS | Build type | Runtime link type | Does it work? |
| --- | --- | --- | --- |
| Windows 7 x64 | Release | shared | no (default configuration of Cutter) |
| Windows 7 x64 | Debug | shared | yes |
| Windows 7 x64 | Release | static | yes |
| Windows 10 x64 | Release | shared | yes |
| Windows 10 x64 | Debug | shared | yes |

This solution cannot be used because of different behavior of MSVC 2017 shared CRT.

1. Make fixes in radare2. First of all enable _UNICODE and UNICODE defines when building r2 (because Cutter is also have them). Fix the rest places which uses functions like open for file access - that is under development. The hardest part is to not break the r2 code for other systems.

P.S. If I compile r2 with unicode support and open unicode-named file with w32 IO it opens the file, but then, internally it is being reopened with bad name and the following analysis fails at all:

So, I'm not give up and continue trying the third approach. If you have any hints - would be good :)

[a1ext]

Also, I think the rest of IOs have to be checked and fixed as well...

[a1ext]

Seems like we are almost done with this, need to do some testing, PR to radare2 and then PR here.