最近、安いステーキ屋に行った時に、10分程注文を待たされたことがあった。 つまり、お茶だけ出された後注文を取りに来ないのである。嫌がらせされている という感じではなく、単に注文を取りに来るのを忘れているのである。ちょうど 読みたい本を持っていたのでそのままずっと待っていたのだが、もし最後まで読 みきっていればそこで帰っていた所だ。とにかく、本を読む速度よりも注文を取 りに来る方が早かった。
注文したら、今度はサラダが出てこない。
こういう場合に怒る人もいると思うし、それも当然ではあるが、プログラマー たるものはこんな絶好の機会があったら真っ先に原因を追及しなければならない。 まず、この障害はここだけに発生しているのか。そうではなさそうだ。他のテー ブルでも同様の障害が発生していたからである。となると、店の人のやる気の問 題だろうか。結構忙しいように見える。つまり、ここがポイントらしい。忙しい 割に人が足りないのである。だから、店側のパワーが100%稼働状態であっても客 に対応し切れないのだ。じゃあどうするか。アルバイトを雇ってパワーを増強す るか、あるいはやむを得ない措置としては、店のキャパシティを一時的に抑制す るか。理想的には、個人の技術を向上することによって生産性を高めるという選 択肢もありそうだが、どうも様子を見た限りでは店の人も頑張っているようで既 に一定レベルに到達しており、これはあまり期待できそうにない。
というようなことを考えながら肉を食う人というのも珍しいと思う、などとメ タに考えてみた。
これが、以前ならオフィスなり自宅なりで我慢していればよかったのだが、最 近様子が変わって来た。どこにいてもベルの音が聞こえるのである。幻聴ではな い。つまり、携帯電話のベルの音なのだ。あれはすごく心臓に良くないと思う。 fjなどで、携帯電話の出す電波が周囲に影響を与える話が一時話題になっていた し、今もなっている。特に、ペースメーカーに近い距離で携帯電話を使った場合 にペースメーカーが誤動作するのではないかという疑問が興味深い。実際、携帯 電話を何cm以内で使うと安全とは言えない、というようなガイドラインがあった ようだ。もっとも、実際に山手線で密着状態で携帯電話が鳴ったりすると、ペー スメーカーの数cmの距離で電波が出る可能性もあるのだが、実際にそれが原因で 惨事になったという話はまだ聞いたことがない。
しかし、ペースメーカーならまだ携帯電話との関連性が主張できるかもしれな いが、仮に電車の中で携帯電話のベルの音が鳴って、それが原因でショック死し てしまったような場合、一体誰に責任があるのだろうか。電波はともかく、音が 危険というガイドラインは聞いたことがないのである。
外に出ていても電話のベルの恐怖に脅かされることを世間が強いるというのな ら、こっちも考えがある。てなわけではないが、携帯電話をほとんど衝動的に購 入してしまった。これで便利なのは正にどこからでもNIFTY-Serveにアクセスでき るということである。例えば、喫茶店の中でTP230Csを使って文章を書いて、その 場でメールを出すことができる。実は近くのグレ電(灰色のISDN公衆電話のこと) まで行けば別に携帯電話がなくてもe-mailは出せるのだが、これが結構大変だっ たりすることがよくある。例えば、1台しかないグレ電で長電話して出てこない人 がいたり、グレ電がなくて見渡す限りの緑の電話とか。新宿西口のJR出口あたり でグレ電のある場所を発見するまで、この付近からe-mailを出すのは多少躊躇し ていたのだ。
これ専用のカードモデムも買って、早速アウトドアからアクセスしようとして みたが、そう簡単には行かなかった。ダイアルした途端にNO CARRIERと出たり、 OKとだけ表示されて繋がらなかったり、いろいろ試行錯誤してみたら、結局
atd,03-5710-6222
としていた個所を
atdt03-5710-6222
としたらうまく繋がるようになった。携帯からかける時にはatdtじゃなくてatd とするのだ、ということを前もって聞いていたので、その通りにしたのだが、何 てことはない。考え過ぎである。しかし、atdtでうまく行くのにatd,だと変、と いうのはちょっと理解できない。これはちょっと原因を想像できない。しかし、 うまく動作してしまった場合には、あまり原因を追及しないという習慣もある。 あまり良い習慣ではないかもしれないが、世渡りのテクニックの一つである。
ここで話題になったのが、echoというコマンドの所在で、これはシェルの組み 込みコマンドなのか、いや、/usr/bin/echoにあるとかいう話題の後で、echoとい うコマンドを勝手に作ってしまうことになって、動作は秘密だが、さくっと作っ たのがリストのプログラムだ。
ここで、コメントアウトしてあるfree(buf - 1); という所が問題である。これ をコメントアウトしたのは、必要ないからである。当たり前だというのは気が早 い。必要ないのならなぜコメントで書いたかという話になる。実は、このプログ ラムは最初、bufの値に1加えたらそのまま処理を続行して、最後に1を引いてfree するようになっていたのである。通常、獲得したポインタを1加えて使うというこ とはしないから、後で修正する時にうっかりfree(buf);すると危険と思ってこれ をコメントで残しておいたのだ。
ところが、さくっと作っている間に、作業用の変数がもったいないと思って省 略して、bufという変数をそのまま使うことにした。すると、free(buf - 1)なん てとんでもない話で、そこで暴走するのである。つまり、これをコメントから外 すと大変なことになる。こうなると何のコメントだか訳が分からないが、とにか くコメントになっている限り、このプログラムは正しく動作する。時限爆弾みた いなものになったしまったようだ。
このプログラムだが、最初にmallocしているあたり、どうも面白くない。瞬間 的に作ったから仕方無いのだが、reallocにNULLを使う方法を知っていれば、my_ reallocを流用することもできて、my_mallocなどという関数は不要なのである。 それに、最初に1バイト確保してポインタに入れている処理も、結局長さ0だと printfを一度も呼び出さないのだから、bufを素直にNULLで初期化しておけば最初 にmy_mallocを呼ぶ必要すらないのだ。
しかも、このプログラムはネットで見ている人はいいが、もしかして印刷する とやばいかもしれない。1(いち)という定数が結構よく出てくる場合は、l(エル) という変数を使わないのが基本である。見間違うからだ。だいたいデバッグの時 に見間違う可能性もあるわけである。この変数が出てきた理由は、まず長さを入 れる変数としてlenという名前を割り当てる癖があった。ところが、このプログラ ムには既にlenという名前が使われている。そこで、一時的に使う変数名として、 lenから連想したlを使った、という所だろうか。場合によってはlというのはlong を連想させるので、その意味でもあまりよくない名称かもしれない。
とりあえず、こういうことをうだうだと考える性格になっていると、ステーキ の注文を取りに来るのが遅い位では動じないので、よいかもしれない。
/* echo.c
* This program is PDS
* (no copyright)
*/
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
/*--------------------------------------------------------------------*/
static void *my_malloc(size_t size)
{
void *p;
p = malloc(size);
if (p == NULL) {
exit(1);
}
return p;
}
/*--------------------------------------------------------------------*/
static void *my_realloc(void *p, size_t size)
{
p = realloc(p, size);
if (p == NULL) {
exit(1);
}
return p;
}
/*--------------------------------------------------------------------*/
int main(int argc, char *argv[])
{
char *buf;
int len;
buf = my_malloc(1);
*buf = '\0';
len = 0;
argc--;
while (argc-- > 0) {
int l;
l = strlen(*++argv) + 1;
buf = my_realloc(buf, len + l + 1);
strcat(buf, " ");
strcat(buf, *argv);
len += l;
}
len--;
buf++;
while (len > 0) {
printf("%s...\n", buf);
len = (len + 1) / 2;
buf += len;
len = strlen(buf);
}
/* free(buf - 1); */
return 0;
}
---- list end ----