C1XのBounds-checking interfacesの実装に挑戦したい...

まずは、C1XのBounds-checking interfaces が何なのかから説明します。簡単にいってしまえば、メモリへの不正アクセスをチェックできるようにしたライブラリ関数群のことです。大雑把にいえば、Visual C++ 2005 以降で登場した _s 付の関数の標準版のようなものです。

実は以前にも実装に挑戦したことがあるのですが、Visual C++.net 2003 への対応が難しかったので、そこで挫折してしまいました。というのも、Visual C++ 2005 以降であれば、ストリームの排他制御に用いる _lock_file 関数がユーザーに公開されているのですが、2003以前のバージョンでは非公開だからです。静的リンクの場合は強引に使ってしまうこともできるのですが、ランタイムライブラリをDLLにしたい場合はどうしようもありません(同じものを再実装するという手はありますが...)。

私の場合、Visual C++.net 2003 はまだまだ現役です。というのも、2005 以降だとデバッグモードが遅すぎて使えないことも多々あるからです。いろいろなチェックをやめればある程度は改善されるのでしょうが、IDEがそもそも重いので、2003で済む場合は2003を使いたいのです。

ただ、問題になるのはマルチスレッドかつDLLの場合だけですので、自分の使用状況を考えると、シングルスレッドかつ静的リンクのことが多いので、使えないわけではありません。それか、いっそ 2005 以降だけと割りきって、このライブラリを使う場合は 2003 は使えないということにしてしまったほうがよいのかもしれません。

あと、ライブラリを実装するにあたって、正直に仕様通り実装すべきなのか、思い切ってC++だけでしか使えないことにして、ext1 名前空間でも使うことで、Visual C++の同名関数との衝突を避けるのがよいのか、いろいろ悩むところではあります。正直な実装の場合、__STDC_WANT_SECURE_LIB__ マクロの定義を殺して、同名の関数の宣言を抑止しなければなりません。その上で、__STDC_WANT_LIB_EXT1__ マクロの定義状態を見て、_s 付関数の宣言を行うかどうかを決めなければなりません。

ほかには、freopen_s の実装で、共有モードを扱わないといけないわけですが、_fsopen はあっても _fsreopen というのがないので困った記憶があります。_fsopen と freopen のソースを参考にしながら、スクラッチしかないのかもしれません。printf 系と scanf 系の関数もスクラッチになりますが、これは手間だけの問題です。

どうせ実装するならGCCでも使いたいわけですが、思ったより再利用できる部分が少ないという予想をした記憶があります。もちろん、大部分は再利用できるのですが、予想に反してということです。自分で作るより前に、glibc が先に対応してしまいそうな気もしますが、Cygwin や MinGW のこともあるので、やっても無駄にはならないでしょう。VC++ はおそらく将来にわたって対応しそうにないので、無駄になることはないと思っています。

いずれにせよ、しばらく時間がとれそうにもないので、4月以降にでも何とかできればと考えています。

この記事のトラックバックURL:

http://www.kijineko.co.jp/trackback/708