結論は問題ないけど、途中の解説がちょっと違うような気がするので、元記事を補足する意味で書き残しておく。
これはShift-JISコードの「表」の文字コードはUTF-8では扱えないことを意味します。gccコンパイラは内部では文字列をUTF-8として認識してコンパイルするので、こうした問題がでてきます。
Shift-jisの「表」でコンパイルエラーが出るのと、gccが内部でUTF-8を使っているのは関係がない。理論上おそらくgccの内部がShift-jisだったとしてもこの現象は起こる。たぶんUTF-8が存在する前から起きていた。
なお「表」を「表¥」とするとコンパイルエラーにならない。Shift-JIS問題は他のコンパイラ、他の言語でもおきるので、コンパイラではなく文字コード単独の問題。
「表」の文字は先頭部分が「\」と同じ文字コードを表していてエスケープシーケンス文字（制御文字）として扱われることになってしまいます。
これは「表」の文字コードが「95」「5c」で、「5c」が「¥」だ、と言いたいのだと理解した。だとすると「先頭」ではなく「後ろ」ではないかなと…。
それから「エスケープシーケンス文字」は、厳密な意味では「制御文字」ではない。バックスラッシュがプログラミング上意味を持っているだけで、文字としては普通の記号。
コマンドプロンプトをUTF-8モードにしても入力までUTF-8になっている訳ではないようです。
仕組みとして、chcpは表示を変えるだけなので、コンパイルしたプログラムに後から変更が加えるわけではないよ、と。エディタでShift-JISで書かれたファイルをUTF-8や他の文字コードとして開いてしまうと文字化けするけれど、それと同じようなもの(？)だ。
また、プログラムが出力するバイナリ値自体も変わっていない。ソースコードがUTFで「トマト」と書かれていればUTFの「トマト」、shift-jisならshift-jisの「トマト」の文字コードを出している。
同様に入力を変える効果もない。入力を渡すのは自作プログラムのほうではなく、コマンドプロンプトなので、受け付けられた文字＝shift-JISは変更されない。
プログラムの方も、入力された文字がshift-jisかUTF-8か、はたまた他の文字列か自動判定はしない。Shift-JISの「赤」と、UTF-8で保存された「赤」は別の数値なので、比較で一致しない、となる。
これはwindowsに限らず、またgccに限らず、「入力文字コードとソースコードの文字コードが違えば全部起きる」問題なので、組み合わせは無数にある。
今回は入出力が固定されているからgccのオプションで良いけれど、読むこむファイルが何の文字コードか分からない(メールなど)、ということもあるので、プログラム内でデコード、エンコードする方法も紹介したいなと思った…けど良いリンク先がみつからなかった。
Cだとデフォルトで汎用的な文字コードライブラリが付属しないから面倒だよね、というのを思い出した日でした。