MSYS2/MINGW64環境を使いfputwcで日本語を出力したい

Question

実現したいこと

• MSYS2/MINGW64環境でfputwcで日本語を出力したい

前提

• MSYS2環境のmintty上で、下記スクリプトを実行する
• 実行して出力されるCプログラムを同じく実行してビルド・実行し、端末上に本という文字を表示させたい
• chcpは932を出力する
• minttyの設定はデフォルト
• C部分だけを修正する
• MSVCRT.dllのfputwcを使用する

発生している問題・エラーメッセージ

以下のようにfputwcは何も表示出来ず、意図通りにロケールに932が設定されているが、なぜか何も表示されず、意味不明な戻り値とエラーが設定されている。

$ bash test_fputwc.sh
Japanese_Japan.932
test_fputwc: No space left on device
failed! errno=28 r=65535
stdout test finished

$

該当のソースコード

cat >test_fputwc.c <<EOF
#include <stdio.h>
#include <wchar.h>
#include <locale.h>
#include <errno.h>
void test(FILE* fp) {
    wint_t r = fputwc(L'本', fp);
    if (r==WEOF) {
        perror("test_fputwc");
        printf("failed! errno=%d r=%d\\n", errno, r);
    } else {
        printf("success...0x%04x\\n", r);
    }
}
int main(int argc, char* argv[]) {
    printf("%s\\n", setlocale(LC_CTYPE, ""));
    test(stdout);
    printf("stdout test finished\\n");
    // FILE* fp = fopen("hoge.txt", "wt");
    // test(fp);
    // fclose(fp);
    // printf("file test finished\\n");
    return 0;
}
EOF
gcc -g -Wall test_fputwc.c -o test_fputwc
./test_fputwc
# iconv -f cp932 hoge.txt

試したこと

コメントにした部分を解除し、標準出力ではなくファイル出力を試みた。
結果、以下の出力を得た。

$ bash test_fputwc.sh
Japanese_Japan.932
test_fputwc: No space left on device
failed! errno=28 r=65535
stdout test finished
success...0x672c
file test finished
本
$

標準出力ではなくファイルに出力した場合は正しく出力されている。
なぜこういう動作になるのか理由が分からない。

補足情報（FW/ツールのバージョンなど）

関連パッケージバージョン
base 2022.06-1
base-devel 2022.12-2
mingw-w64-x86_64-gcc 12.2.0-10

依存ライブラリなど

$ ldd test_fputwc
        ntdll.dll => /c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffe8fcb0000)
        KERNEL32.DLL => /c/WINDOWS/System32/KERNEL32.DLL (0x7ffe8e940000)
        KERNELBASE.dll => /c/WINDOWS/System32/KERNELBASE.dll (0x7ffe8d8b0000)
        msvcrt.dll => /c/WINDOWS/System32/msvcrt.dll (0x7ffe8fbb0000)

最後に

以下の自分の質問の調査中に見つけた疑問点です

「MINGW64で作ったC++プログラムで正しく日本語を扱いたい」
https://teratail.com/questions/la96e9z2k99cw5

---

後出し前提条件

• リダイレクトした場合はロケールに従った出力(システムロケールであるCP932)になること

追加希望

• MSVCRTを使ったVCであるVS2015をお持ちの方、同様の現象が起きるかご確認して頂けますと嬉しいです

---

注意事項

MSのバグを疑ってMSVCRTの中を追ってたからなのか、Windows Defenderにウィルスとして検出されました。詳細情報を見ても何も分からないので、本当にウィルスである可能性を考慮して一応ご連絡。

Answer 1

Windows のストリームはバイナリモードとテキストモードの他にユニコードモードが存在するらしく、その設定がされていないストリームに対してワイド文字版の出力関数を使うとエラーになるようです。

fcntl.h をインクルードした上で

_setmode(_fileno(stdout), _O_U16TEXT);

の一文を追加すればおそらく期待する動作になります。

追記

標準出力から出力する文字コードはシステムロケールにしたいという条件に対処する方法を調査・検証してみましたが私なりの結論としては MSVCRT はこのような使い方を想定していないか、単純に対応が充分ではない (バグ) ように見えます。 モードの設定などで期待する動作を出来そうな気がしません。

色々と資料を見た感じをおおざっぱに箇条書きするとこんな感じです。

• ストリームには三種類のモードがある
  • バイナリモード
  • テキストモード
  • ユニコードモード、これはさらに三種類に分けられる
    • Unicode (UTF-16, BOM が付く)
    • UTF-16LE
    • UTF-8
• それぞれのモードのストリームにワイド文字出力系関数で出力を試みたときの結果は
  • バイナリモード → UTF-16LE
  • テキストモード → ロケール設定に従う
    • だたし標準出力をこのモードにしたときは何故か出力時にエラーが返る
  • ユニコードモード → ユニコードモードの種類に従う
    • ただしストリームがコンソールに接続されているときは化けないような調整があるっぽい？

需要を考えれば「入出力はユニコードであって欲しいがコンソールでは化けて欲しくない」という場合が多いでしょうからユニコードモードの挙動は望ましいものです。 ただ、コンソールで化けないというのは不自然な場合分けをしているような雰囲気があるので互換性と辻褄を合わせながら需要も満たす無理のある仕組みがあるように見えます。

システムロケールの設定に従って出力して欲しいというのが目的であればストリームはテキストモードにしつつロケール設定するのが筋です。 しかしそれが何故か出力時にエラーになるというのが現時点での問題点です。 しかも返ってくるエラーも状況にそぐわない意味不明なものなので対処法を見出せません。

Comments

[退会済みユーザー]

以下のスクリプトで確認しました。
cat >test_fputwc.c <<EOF
#include <stdio.h>
#include <wchar.h>
#include <locale.h>
#include <errno.h>
#include <fcntl.h>
void test(FILE* fp) {
int mode = _setmode(_fileno(stdout), _O_U16TEXT);
wint_t r = fputwc(L'本', fp);
_setmode(_fileno(stdout), mode);
if (r==WEOF) {
perror("test_fputwc");
printf("failed! errno=%d r=%d\\n", errno, r);
} else {
printf("success...0x%04x\\n", r);
}
}
int main(int argc, char* argv[]) {
printf("%s\\n", setlocale(LC_CTYPE, ""));
test(stdout);
printf("stdout test finished\\n");
//FILE* fp = fopen("hoge.txt", "wt");
//test(fp);
//fclose(fp);
//printf("file test finished\\n");
return 0;
}
EOF
gcc -g -Wall test_fputwc.c -o test_fputwc
./test_fputwc
#iconv -f cp932 hoge.txt

[出力]
$ bash test_fputwc_setmode.sh
Japanese_Japan.932
本success...0x672c
stdout test finished

$

fopenの説明を読んだときに
FILE *fp = fopen("newfile.txt", "rt+, ccs=UTF-8");
みたいな説明をしており、UTF-8をUNICODEかUTF-16LEにしたのが該当すると思っていたので、またUnicodeモードは排他的である旨記載があったため、ファイル書き込み時に怒られなかったこともあり、それではなかろうと思っておりました。ちなみにファイルのオープン時には_O_TEXTしかついていないのを確認までしてたのです。

イマイチ良く分かりませんが、現象が全てなので、これでベストアンサーとしますね。

[SaitoAtsushi]

ファイルが通常のテキストモード出力のときにワイド文字出力を使うと設定されたロケールに従って文字コード「変換」して出力することになっているようで、ユニコードモードでなくても問題なく動作はします。
標準入出力のときに限ってはユニコードモードであることが必要ならしく、ユニコードモードに設定された標準出力は少し特殊な挙動が見て取れます。
ユニコードモードに設定された標準出力をリダイレクトでファイルに出力してみてください。 設定されているロケールに関係なくユニコード (_setmode で設定した符号化) で出力されていることがわかります。
その一方ではコンソールに表示されたときにも化けません。
ロケールに合わせて変換をかけるというだけの挙動ではないんだと思います。 私も細かいことはよくわかりませんが。

[退会済みユーザー]

通知なくて気付きませんでした。
こちらでも調べてみて、まるで違う出力になることに気付きました。
欲しい挙動はロケールに従って動作することです。
ユニコードモードではロケールによらずストリームそのものがUTF-16LEに強制されるようで、リダイレクトした場合も同様に動作します。
前提に書いたことは満たしているのですが、欲しい物ではないのでベストアンサーは外しますね。
一言で言えば原因はそこではないということです。
例えば元の質問にあるコードで「本」ではなく「A」を出力するとワイド文字でも出力されるからです。
これをリダイレクトすると、1バイトになります。

[退会済みユーザー]

回答追記ありがとうございます。概ね認識は一致しているようですね。
仕様については参照して引用くらいに抑えるべきというスタンスなので、普段必要以上に記述していませんが、認識の一致を確認する目的には良いですね。Unicodeモードは多分例によって誰も使ってないMS仕様の1つだと思います(何となくPowerShell辺りを意識したワイド系への流れを強制したかった過去の仕様なのかなと思ってる)。

個人的な推測では最初から「単純に対応が充分ではない (バグ) ように見えます」なのです。
追うのがしんどかったので、並行して情報がないか募っていたわけです。
現時点ではgdbで追っかけてますが、wctomb_sを使った「本」のUnicode値をCP932の値に変換してるところまでは確認でき、その後の非公開関数の_flsbufというどうやらfputcのような挙動をする関数にCP932のバイト値ではなくUnicode値を放り込んで失敗してるように見えます(asciiが通るのも説明できる)。非公開な上に名前も意味不明なので分かりませんが、そういうレベルでバグっぽいです。

[退会済みユーザー]

Unicode値を放り込んで失敗は私の見間違いだったようです。

Answer 2

回答

現状では個人的に不可能と言わざるを得ません。

原因

setlocale()で設定されたロケールに従いって端末出力する場合、_write()が2バイト文字の1バイト目のみを出力しようとすると、errno=ENOSPCなエラーとなるから。fputwc()は2バイト文字の1バイト目を出力するために_write()を使用する。

https://learn.microsoft.com/ja-jp/cpp/c-runtime-library/reference/write?view=msvc-140

を見る限り、_write()にそのような仕様はない。

対策

VS2015がなく、この挙動がMINGW64によるビルドの影響なのか、MSVCRT.dllの実装のせいなのか、切り分けられないので、個人的には対処のしようがない。
→(個人的には)不可能

調査詳細

調査用スクリプト

cat >test_write.c <<EOF
#include <stdio.h>
#include <locale.h>
#include <io.h>
#include <errno.h>
void test(char* s, size_t len) {
    int r = _write(_fileno(stdout), s, len);
    if (r != -1) {
        printf("r=%d\\n", r);
    } else {
        perror("test_write:");
        printf("r=%d errno=%d\\n", r, errno);
    }
}
int main() {
    setlocale(LC_CTYPE, "");
    printf("[_write(1, \\"\\\\x96\\", 1)]\\n");
    test("\\x96", 1); // 本のCP932の1バイト目だけ
    printf("[_write(1, \\"\\\\x96\\\\x7b\\", 2)]\\n");
    test("\\x96\\x7b", 2); // 本のCP932の1文字分
    return 0;
}
EOF
gcc -g -Wall test_write.c -o test_write
./test_write
cat >test_fputwc.c <<EOF
#include <stdio.h>
#include <wchar.h>
#include <locale.h>
#include <errno.h>
void test(FILE* fp) {
    wint_t r = fputwc(L'本', fp);
    if (r==WEOF) {
        perror("test_fputwc");
        printf("failed! errno=%d r=%d\\n", errno, r);
    } else {
        printf("success...0x%04x\\n", r);
    }
}
int main(int argc, char* argv[]) {
    setlocale(LC_CTYPE, "");
    test(stdout);
}
EOF
gcc -g -Wall test_fputwc.c -o test_fputwc
gdb ./test_fputwc <<EOF
r
b _write
r
where
info register
x/16bx \$rdx
delete 1
c
q
EOF

バージョンアップなどで将来挙動が変わる可能性もあるので、ログも控えておきます。

$ bash test_write.sh
[_write(1, "\x96", 1)]
test_write:: No space left on device
r=-1 errno=28
[_write(1, "\x96\x7b", 2)]
本r=2
GNU gdb (GDB) 13.1
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-w64-mingw32".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./test_fputwc...
(gdb) Starting program: C:\msys64\home\user\mingw\test_fputwc.exe
[New Thread 16188.0x4b88]
test_fputwc: No space left on device
failed! errno=28 r=65535
[Thread 16188.0x4b88 exited with code 0]
[Inferior 1 (process 16188) exited normally]
(gdb) Breakpoint 1 at 0x7ffe8fbcfaeb
(gdb) Starting program: C:\msys64\home\user\mingw\test_fputwc.exe
[New Thread 17372.0x62bc]

Thread 1 hit Breakpoint 1, 0x00007ffe8fbcfaeb in msvcrt!_write ()
   from C:\WINDOWS\System32\msvcrt.dll
(gdb) #0  0x00007ffe8fbcfaeb in msvcrt!_write () from C:\WINDOWS\System32\msvcrt.dll
#1  0x00007ffe8fbf719e in msvcrt!_flsbuf () from C:\WINDOWS\System32\msvcrt.dll
#2  0x00007ffe8fbfd521 in msvcrt!fputs () from C:\WINDOWS\System32\msvcrt.dll
#3  0x00007ffe8fbfd5ed in msvcrt!fputwc () from C:\WINDOWS\System32\msvcrt.dll
#4  0x00007ff74ccd14c4 in test (fp=0x7ffe8fc3fa30 <msvcrt!_iob+48>) at test_fputwc.c:6
#5  0x00007ff74ccd155e in main (argc=1, argv=0xd4870) at test_fputwc.c:16
(gdb) rax            0x40                64
rbx            0x7ffe8fc3fa30      140731310406192
rcx            0x1                 1
rdx            0x5ffd90            6290832
rsi            0x1                 1
rdi            0x0                 0
rbp            0x1                 0x1
rsp            0x5ffd00            0x5ffd00
r8             0x1                 1
r9             0x5ffdb6            6290870
r10            0x0                 0
r11            0x5ffd40            6290752
r12            0xd48b0             870576
r13            0x0                 0
r14            0x5ffdb4            6290868
r15            0x0                 0
rip            0x7ffe8fbcfaeb      0x7ffe8fbcfaeb <msvcrt!_write+27>
eflags         0x206               [ PF IF ]
cs             0x33                51
ss             0x2b                43
ds             0x2b                43
es             0x2b                43
fs             0x53                83
gs             0x2b                43
(gdb) 0x5ffd90: 0x96    0xff    0xff    0xff    0x00    0x00    0x00    0x00
0x5ffd98:       0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
(gdb) (gdb) Continuing.
test_fputwc: No space left on device
failed! errno=28 r=65535
[Thread 17372.0x62bc exited with code 0]
[Inferior 1 (process 17372) exited normally]
(gdb)

簡単な解説

まずは_write()の挙動を確認するためのCファイルtest_write.cをビルドして実行しています。実行結果の

[_write(1, "\x96", 1)]
test_write:: No space left on device
r=-1 errno=28

という部分から、_write()でCP932の2バイト文字を1バイト分しか書き込もうとしなかったときに、fputwc()と同じ現象が発生してることが確認できます。

あとはfputwc()から_write()が呼ばれることを実証できれば因果関係が確認できます。そのためにtest_fputwc.cを生成、ビルドして、gdbというデバッガで実行しています。このデバッガはコマンドで動くタイプなので、コマンドをhere documentで直に記述しています。

やっていることは、一度実行してDLLを読み込ませ、_write()にブレークポイントをしかけて実行し、止まったらコールスタックを表示し、引数を見るためにレジスタを表示し(第1引数がrcx, 第2引数がrdx, 第3引数がr8)、第2引数はポインタなのでメモリのダンプをしているだけです。あとはブレークポイントを解除して残りの処理を実行させて終わりです。

---

追記

若干調査してわかったことがあるので追記しておきます。

locales=("C" ".932" ".UTF-8" ".65001" ".20932")
first=("\\x96" "\\x96" "\\xe6" "\\xe6" "\\xcb")
second=("\\x7b" "\\x7b" "\\x9c" "\\x9c" "\\xdc")
third=("" "" "\\xac" "\\xac" "")
for i in `seq 0 4`;do
    loc=${locales[$i]}
    fbase="test_write_locale_${loc}"
    cat >${fbase}.c <<EOF
#include <stdio.h>
#include <locale.h>
#include <io.h>
#include <errno.h>
void test(char* s, size_t len) {
    int r = _write(_fileno(stdout), s, len);
    if (r != -1) {
        printf("r=%d\\n", r);
    } else {
        perror("test_write:");
        printf("r=%d errno=%d\\n", r, errno);
    }
}
int main() {
    if (setlocale(LC_CTYPE, "${loc}") == NULL) {
        fprintf(stderr, "setlocale fail!\\n");
        return 1;
    }
    printf("[_write(1, \\"\\${first[$i]}\\", 1)]\\n");
    test("${first[$i]}", 1); // 本の1バイト目だけ
EOF
    if [ "${second[$i]}" != "" ]; then
        cat >>${fbase}.c <<EOF
    printf("[_write(1, \\"\\${first[$i]}\\${second[$i]}\\", 2)]\\n");
    test("${first[$i]}${second[$i]}", 2); // 本の2バイト目まで
EOF
    fi
    if [ "${third[$i]}" != "" ]; then
        cat >>${fbase}.c <<EOF
    printf("[_write(1, \\"\\${first[$i]}\\${second[$i]}\\${third[$i]}\\", 3)]\\n");
    test("${first[$i]}${second[$i]}${third[$i]}", 3); // 本の3バイト目まで
EOF
    fi
    cat >>${fbase}.c <<EOF
    return 0;
}
EOF
    gcc -g -Wall ${fbase}.c -o ${fbase}
    echo "=== ${fbase} ==="
    ./${fbase}
done

スクリプトを修正して他のロケールでどうなるか？UCRT64でどうなるか？を見てみました。

MINGW64での結果

=== test_write_locale_C ===
[_write(1, "\x96", 1)]
睦=1
[_write(1, "\x96\x7b", 2)]
本r=2
=== test_write_locale_.932 ===
[_write(1, "\x96", 1)]
test_write:: No space left on device
r=-1 errno=28
[_write(1, "\x96\x7b", 2)]
本r=2
=== test_write_locale_.UTF-8 ===
setlocale fail!
=== test_write_locale_.65001 ===
setlocale fail!
=== test_write_locale_.20932 ===
[_write(1, "\xcb", 1)]
test_write:: No space left on device
r=-1 errno=28
[_write(1, "\xcb\xdc", 2)]
本r=2

UCRT64の結果

=== test_write_locale_C ===
[_write(1, "\x96", 1)]
睦=1
[_write(1, "\x96\x7b", 2)]
本r=2
=== test_write_locale_.932 ===
[_write(1, "\x96", 1)]
睦=1
[_write(1, "\x96\x7b", 2)]
本r=2
=== test_write_locale_.UTF-8 ===
[_write(1, "\xe6", 1)]
[_write(1, "\xe6\x9c", 2)]
[_write(1, "\xe6\x9c\xac", 3)]
本r=3
=== test_write_locale_.65001 ===
[_write(1, "\xe6", 1)]
[_write(1, "\xe6\x9c", 2)]
[_write(1, "\xe6\x9c\xac", 3)]
本r=3
=== test_write_locale_.20932 ===
[_write(1, "\xcb", 1)]
?=1
[_write(1, "\xcb\xdc", 2)]
本r=2

わかったこと

• "C"ロケールでは問題が発生しないこと
• UCRT64では問題が発生しないこと
• MINGW64(MSVCRT)ではコードページ20932(EUC-JP)でも同様の問題が発生していること
• EUC-JPで正しく表示されていることからbreakpointで仕掛けてみたところ、_write()呼出中にMultiByteToWideChar()とWideCharToMultiByte()が呼ばれていた。つまりMSVCRTでも端末のコードページに合わせてエンコーディングの変換をかけている。