undocumented feature

昔々のことになりますがNECのTK-85を持っていました。CPUはインテルの8085で、RAMは何と僅か512バイトです。

8085というCPUは、有名な8080を改良したもので、命令が2つ追加されています。当時のインテル製CPUのアーキテクチャはCISCです。命令長は可変長ですが、命令の1バイト目だけみれば後続する命令長が分かるようになっています。要するに1バイトで命令をデコードするわけですから256個定義できるのですが、実際には数箇所の未定義部分があります。

当時のCPUは現在とは違い原始的ですので、未定義となっている命令を実行させようとしても「例外処理」が起きるような機能を持っていません。未定義命令を使ったバイナリを実行させてみると、思いもがけないような結果が得られることがあります。アセンブラでプログラムを書く身であれば在れば有り難いと思うような機能が実装されているのが分かったりします。しかしそれはマニュアルに記載されていませんから必ず利用できるとは保証されません。このような機能は「undocumented feature」と呼ばれます。

ここまで書いた話はハードウェアに関することですが、ソフトウェアであっても同じことです。ハードであれソフトであれ、仕様に関する文書に記載されていない場合でも、操作してみれば何らかの「一見すると有用そうな」挙動を示すことがあります。しかしそれは（厳格に捉えるなら）undocumented featureです。つまりその「機能」は永続的に利用できる保証がありません。

このようにundocumented featureを使うのは慎重となるのですが、問題は特にOSSでは仕様を明示的に示す文書が欠けていることが多いことです。あろうことか「ソースコードが公開されているんだから、文書は要らない」とか言い出す人が出てくる始末です。仕様書とソースコードが同一だとする立場であれば、そこには「バグ」という問題は原理的に発生しません。バグというのは、仕様としてあるべき状態と、プログラムとしての実際の挙動の違いから判断されるべき事柄なのです。

商用製品では、OSSに比べれば 、文書がある程度用意されていますが、些細な点まで全て網羅されているような詳細な文書が用意されているとも限りません。使おうとした機能や、行おうとした操作が、undocumented featureなのか否かを判断するのは、思うほど簡単ではありません。

このようにundocumented featureは恐いので、使わないで済むものなら使いたくないところです。問題は、文書が充実しているとは言い難いことが多い現状においては、確実に「仕様に基づいた機能を使っている」と言い切れる事態は決して多くはないという事実です。否応なしに、undocumented featureを利用しているのか違うのかも不明なままに、目の前で動いているものが「永続的」であるように祈りながら、日々を過ごしていくことになります。