多言語対応は難しい
まずは問題を認識して落ち着いて対処しないといけない気がする。
ファイル名の多言語対応はセキュリティ問題
Unicodeでは、いわゆる￥(U+00A5)と＼(U+005C)が別々に取り扱えるので何も考えずにUnicodeでないopenを使うとディレクトリトラバーサルが可能になる。つまり、通常のシチュエーションでは￥は＼に変換される(そして、非Unicodeな関数ではどちらもディレクトリセパレータに見える)ため、意図しないディレクトリのさかのぼりを防ぐためには両方をチェックしなければならない。
要するに、日本語ファイル名のサポートを無視して非Unicode版のfopenを使うのは基本的に安全でない。もちろん、チェックルーチンをOSごとに準備するという手も有るが。。
(ちなみにC++なら、VC2008のstd::fstreamにwchar_tなopenが存在するのでそれを使える。)
ファイル名の仕様はOSごとに異なる
ファイル名に許可する文字セットはOSごとに異なる。
MacOSとWindowsは歴史的な理由によりファイル名の大小文字を区別しないモードを備える。そのため、アプリケーション間でファイル名をやりとりする可能性がある場合は大小文字を無視するかどうかも継承する必要がある。
Windowsはパスセパレータとして\も使える(一般にランタイムライブラリが差を吸収するが、Schemeコード側でパスを検証する際に問題になる可能性がある)*1
また、Windowsのパスは通常のパスには無い2つの構文バリアントがある。"c:\"のようにドライブ名を含んだものと、"\\HOST\"のようなUNCパス。『あるディレクトリの上位ディレクトリを提供する』のようなライブラリはこれらを配慮しないといけない。
もっと重要な違いは、R6RSの想定しているファイルはデバイスファイルとかFIFOとかFile mapping objectでは無いので、OS側のopenとR6RS側のopenは本来対応しない点。
TCPソケットを作るためにDNSによる名前解決とかプロトコルの解決が必要なのと同じように、本来ファイルを開くと言うだけの動作でも"パスオブジェクト"を解析し、それをボリュームにマップするという作業が生じる。いわゆるLLは大抵この点を無視しているので本質的に移植可能なプログラムを書くことは出来ない。(だから実用上は移植性について気にしすぎる必要は全くない。スクリプトを書く側がOS側の動作を意識し、かつ、移植可能なプログラムが書きやすい仕様さえ実現されていればそれで良いことになる。)
パフォーマンス問題になりうる
多くの場合、パス名の変換は一度で良いのにもかかわらず、openの度にtranscoderを生成するのが正しいのかは微妙な問題といえる。
実装レイヤ
個人的にはFFIでOSの各種関数をwrapする以外はスクリプト/ライブラリ側でどうにかする方が好ましい気がするが、まぁパフォーマンスが受け入れ可能かという重要な問題なのでなんとも言えない。
何をリテラルにすべきか
で、ここからが本題。
パスリテラルというものは果たして存在すべきだろうか。
moshを例に取ると、正規表現は文字列ではなくリテラルとして存在している。つまり、ソースコード中の正規表現記述から正規表現を処理するオブジェクトを作り(多分将来的にはJITCして)利用することも原理的には可能になっている。
一般の文字列から正規表現オブジェクトを作ることが出来るかどうかは、言語処理系にevalを組み込むかどうかと同様の問題といえる。つまり、文字列から正規表現を作ることを許可する場合、正規表現をコンパイルして動作させたければJITCするしかなくなる(AOTCできなくなる)。
さて、同様にして、パス名もリテラルにしてしまうことで、事前にパス名の文字コードを変換するだとかの各種作業が可能になる可能性がある。パス名だけではなく、
といったものも、通常の内部string(ucs4)でなく、予めエンコードされたオブジェクトにすることに一定の意義があるかも知れない。
メリットは、言語処理系からevalを廃するのと同様の理由。処理系がより安全になり、動作前のチェックが容易になる。
