仕事で使うマイコンたいてい「C言語」でプログラム
しています。
昔はアセンブラばっかしだったんで、良い世の中にな
りました。(遠い目)
しかしバグ取りの方法はあまり変わりません。
実機でプログラムを動かし、いろんな条件を変えて、
スカタンな動作をしないかどうか、あれこれ検証して
悪いところを見つけます。
これの積み重ねで、まともに動く装置が出来上がって
いくわけです。
プログラムの変更、アセンブラの時代はROMの書き
換えでした。
今は、便利なツールがいっぱい。
おかしいところを見つけた時・・・
組んだプログラムにはおかしいところが見つから
ないぞ。
こんなとき、
新しいハードだと、回路がおかしいかも?
おかしなところを、装置を動かしながら
「見える」ようにしてみよう。
などと、テストプログラムを書いたりします。
しっかり動きを確認しながら、プログラムをまとめて
いくわけです。
ややこしい装置だと、テストプログラムの方が大きく
なったりします。
※量産時の検査用ルーチンのほうが、実際の動作
をするプログラムより場所をとっているなんて
こともあります。
さて、そのおかしなところへの対策でした追加が、
また新たな虫を産むなんてことが生じます。
本人は対策したつもりになっているので「あれれ?」
でっす。
先日はこんな失敗を・・・
単純にして示します。
if(x) // 条件x
a1();
else // それ以外
b1();
条件「x」の時は、処理「a1」を実行。
それ以外は処理「b1」をというルーチンです。
a1あるいはb1、どちらかが実行されます。
プログラムを進めていて、このルーチンの前処理
としてちょいとプログラムを追加したのです。
こんな具合。
if(y) // 条件yなら
c1(); // c1を実行を追加
if(x) // ↓元の処理
a1();
else
b1();
条件「y」での処理を前処理として、追加したわけ
です。
しかし、落とし穴。
処理「c1」は「y」の条件で実行されるかされないか。
その後、「a1」か「b1」どちらかが実行されます。
しかし、処理「c1」で出た結果が、処理「a1」の中で
変えられることがあったのです。
これが失敗。
おかしな状態になるのは「xとy」の条件が重なった
時だけ。
だもんで、「あれれ?」だったのです。
追加した条件判断「y」では、c1だけを実行して後の
処理をスキップするのが正解でした。
こんな具合に修正して、思惑通りの処理になりました。
if(y)
c1();
else if(x) // ←このelseが重要
a1();
else
b1();
これで、「c1」「a1」「b1」はどれか一つしか実行
されません。
最初から、「こうだ」と考えに至っていれば、こんな
ミスはしないんです。
「バグを見つけてそのバグ殺しに追加した処理が
新たなバグを産む」
この手の、ちょいミス、痛いんですよね~。
(新たな虫探しに余計な時間を食ってしまう)
最近のコメント