エラー番号
入社してから数年が経ち、ようやく仕事にも慣れてきた私は、毎日意欲的に仕事をこなしていました。
当時の私は、どのプロジェクトでも利用可能な汎用的機能を集めた共通ライブラリの開発（C言語）に携わっていました。
私の担当は、とあるメモリ領域を同サイズに等分し、それぞれを貸し出したり返却したりする機能でした。
私はその機能を「メモリブロック管理」と名付け、愛着を持って開発してきました。
今から20年ほど前の出来事です。
「貸し出すメモリブロックがなくなった場合のエラーなんだが」
ある日、上司が私に話しかけてきました。
「君はENOBLKという独自のエラー番号を使ってるね？ 『エラー番号はなるべくerrno.hに沿う』というコーディング規約があるんで、それにしたがって直した方が良くないかな。例えばそう、一時的なバッファ不足という意味でEAGAINがいいんじゃないか」
「いいえ、それは違います」
私は得意げにそう言います。
「確かに今回のプロジェクトにおいてはEAGAINでいいかもしれません。しかしこの共通ライブラリは今後、他のプロジェクトでも使われる汎用的なものです。使い方によっては、それが一時的なエラーではない可能性も出てくると思います」
私は話を続けます。
「例えばシステムの起動時に一括に取得し、終了時に返却されるという使われ方をされた場合がそうです。一度取得されたブロックは返却されることがないため、EAGAINが返ってきたからといってリトライされてしまうと、無限ループに陥るかもしれない。メモリブロックの枯渇は、それが一時的なものなのか、それとも回復不可能なものなのか、共通ライブラリのレイヤーでは判断がつかないのです」
私は上司が反論してくるのを待ちました。
自分は正しいことを言っている。
かたくなにそう信じ、上司の反論に応酬するつもりでいました。
しかし、その上司は「そうか」とだけ言って私の元を去りました。
実は上司が関数仕様書にEAGAINと記述し、それがすでに関連部署に配布済みであったことを知っていました。
にもかかわらず、そのときの私は自分の主張を押し通したのです。
正直なところ、メモリブロック管理はその機能特性上、私が例として挙げたような使われ方をされることはまずありえませんでした。
ひょっとすると、私に一言の相談もなく仕様を決めてしまった上司に腹を立てていたのかもしれません。
その後、何も言われなかったため、私はENOBLKを返すコードを修正しませんでした。
しかしなんの問題も出ないまま、製品は出荷されていきました。
ある日、私はとある調査のために共通ライブラリを使用したソフトウェアのコード解析を行っていました。
ふと何かが気になり、共通ライブラリのエラー番号を定義するヘッダファイルを見て驚愕しました。
なんと、ENOBLKはEAGAINと同じ値で定義されていたのです。
さて、あれから十数年の月日が経ち、私はテスター、サーバ管理、PG、SE、PM等ほぼソフトウェア開発に関わるほとんどの役割を経験してきました。
この出来事を思い出し、ふと考えたことがあります。
もしあのとき私が上司の立場だったら、あのくそいまいましいプログラマにどのような対応をしただろうかと。
※この問いへのアンサーとなる記事を以前書いたことがあります。こちら
※当時の連載は読み物として成立させるために、プログラマの特徴を故意に誇張して描いております。