解析に失敗すべきなのに成功するかも、いや結局うまくいかないかも

parserに入力する文字のエンコードをUTF-8にすればシフトJISで起きるような問題は起きないと前述した。
だが、問題がないわけではない。いや、問題にならないかもしれない。
メタ文字変更シーケンスの3文字目はcharの範囲で表現できること前提だが、
例えばUTF-8で「(誤)」とすべきところを誤って「((誤)」のような文字列として与えると、

$ echo -n "((誤)" | iconv -t UTF-8 | od -t x1
0000000 28 28 e8 aa a4 29
0000006

「誤」の1バイト目の0xe8がマーク開始文字'\xe8'と解釈される。
その後、「誤」の2バイト目と3バイト目の「aa a4」がマーク外の文字列として扱われ、
マーク終了文字'\x29'、すなわち')'の出現をもって構文エラーとなる。
この場合は元々間違った入力がエラーになるだけだが、
入力文字列次第では解析に失敗すべきにも関わらず偶然上手く解析に成功する可能性があるだろう。
そうした例を意図的に作成するのは面倒なのでここでは示さない。
このようなケースはUTF-8だけの問題でなくシフトJISなどでも起こりうる普遍的なものである。

しかしさらに考えると構文エラーは起こさずとも入力に無かった文字が現れることがほとんどだろう。
UTF-8のように正しいバイトシーケンスの範囲が狭いものならば、
文字としてあり得ないバイトシーケンスが含まれているとしてエラーになることも少なくないと思う。
そうだとすると、失敗すべき入力に対しては何らかの失敗が起きるであろうから結局大丈夫なのかもしれない。