バグ検出ドリル(7)やっぱり、いろんなところにバグがいる!:山浦恒央の“くみこみ”な話(107)(3/3 ページ)
重要顧客の前でデモを行う際にバグが発生すると大変です。顧客だけでなく、自社の社長まで同席していたいたときなどは、さらにものすごく焦るのではないでしょうか。「バグ検出ドリル」の第7回では、そんな状況を想定しつつ、いろんなところに潜むバグを見つけ出してください!
3.解答
A君とB君の結果が異なったのは、「外部入力ファイルの中の改行コードが異なっている」ためです。
このプログラムの問題点は、改行コードとして「CR+LF」を前提としていることです。問題文を読んで、「同じソースコードなのに振る舞いが違うということは、動作環境が同じでない可能性があり、改行コードが怪しい」と思った読者は正解です。コンピュータの改行コードは、CR(キャリッジリターン)とLF(ラインフィード)で表します※3)。
今回のプログラムでは、テキストファイルを一文字ずつ読み出し、CRとLFが順番に来た場合、行数をカウントする仕組みです。ですが、別の改行コード、例えば「LF」が設定してあると、CRがいつまでたっても来ないため行数をカウントできず、列数も0クリアできません※4)。
※3)CR、LFという言葉は、タイプライターから来ています。タイプライターは、キャリッジと呼ぶ紙を固定する機構に、紙を差し込んで文字を打ちます。紙を固定してキーを打つと1文字を印字し、紙が自動的に1文字分右側にずれます。紙が行の最後に来るとベルが鳴り、タイピストは手で紙を行の先頭に戻して、紙を1行下にずらします。つまり、紙を行の先頭に戻すことを「キャリッジリターン」、紙を1行下にずらすことを「ラインフィード」と呼びます。ちなみに、キーの並びがアルファベット順でないのは、特定の指が疲れないようにするためとのこと。なお、一番上の段の文字だけで「typewriter」と打てます。
※4)昔、顧客先でプログラムの動作確認をしたときのことです。開発担当でないエンジニアが現地で外部入力ファイルを作成し、プログラムを実行したところ、正しい結果になりません。エンジニアはソフトウェアのバグだと思い、ソースコードを何度も細かくチェックしましたが、バグは見つかりません。エンジニアはその結果を開発者に報告し、原因を調査するように依頼しました。数時間後、開発者から来た回答は、「ソフトウェアのバグではなく、改行コードか文字コードが違っているので、修正してください」でした。
仕様をもう一回確認してみましょう。以下の文面が書いてあります。
(2-3-4)テキストファイルから入力した文字が、改行表すLF(ラインフィード)、その1つ前の入力がCR(キャリッジリターン)の場合は、行数+1、列数=0とし、(2-3-1)を実行する。
つまり、改行コードが、「LF」か「CR」しかない場合、行数のカウントと列数のクリアができません。今回の問題では、B君はA君のプログラムをそのままコピーし、入力データのファイルで、改行コードを「LF」にしたのが原因でした。「再利用」する場合、きちんと内容を理解していないとうまくいきませんね。
改行コードは、OSやテキストエディタの設定に依存します。例えば、Windowsの改行コードは基本的に「CR+LF」、Linuxは「LF」です。Macの昔のバージョンは「CR」だったようです。もちろん、改行コードの設定はテキストエディタ側で変更できます。
これと同じような動作不良はよく聞く話ですが、自分のプログラムで起きると、原因がなかなか分かりません。仕様書に改行コードを明記していることが少なく、書いてあっても、開発者は見ないことが原因でしょう。改行コード以外にも、文字コードでも不整合が起こることがあります。インターネットの黎明期に、Webサイトを閲覧すると、ブラウザの設定によっては、大量の文字化けを起こし、びっくりした人が多いはずです。
4.自己採点シート
今回の自己採点シートを下記に示します。
問題 | 内容 | 配点(点) |
---|---|---|
ファイル検索の問題 | 5分以上考えた | 50 |
データファイルの改行コードが異なることが分かった | 50 | |
上記以外のバグを見つけた | +α | |
リスト5 自己採点シート |
5.終わりに
バグはいろいろな成果物に潜んでおり、原因が分からないと不思議な現象に思えます。今回は、改行コードに着目した問題を出題しました。実行結果が正しくない場合、ソースコードのバグを探しますが、外部入力のファイルのデータが原因ということもありえます。このバグは意外に少なくありません。仕様をしっかり確認しましょう。
東海大学 大学院 組込み技術研究科 非常勤講師(工学博士)
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
- ≫連載「山浦恒央の“くみこみ”な話」バックナンバー
- バグ検出ドリル(6)いろんなところにバグがいる! 2分探索法の問題
「バグ検出ドリル」の第6回で出題するのは「2分探索法」の問題です。ソフトウェア技術者の誰もが心得ておくべき常識的なアルゴリズムである2分探索法ですが、今回の問題では、いろんなところにバグがあります。問題文から、どこにバグがありそうか見つけ出してみよう! - バグ検出ドリル(5)「小さな親切、大きなお世話」な問題
「バグ検出ドリル」の第5回で出題するのは「思い込み」にまつわるバグの問題です。タイトルの「小さな親切、大きなお世話」とは一体何なのでしょうか。問題文から、どこにバグがありそうか見つけ出してみよう! - バグ検出ドリル(4)プログラミングの素質を試すのに最適!? FizzBuzz問題に挑戦
「バグ検出ドリル」の第4回で出題するのは、プログラミングの素質を試すのに最適といわれる伝説の「FizzBuzz問題」。問題文から、どこにバグがありそうか見つけ出してみよう! - バグ検出ドリル(3)それでもプログラマーは数学を知っておくべきだ
「バグ検出ドリル」の第3回で出題するのは、前回に引き続き数学に関係する問題。理系とはいえ必ずしも数学が得意ではないプログラマーですが、やはり数学を知るメリットは絶大。これまでと比べてかなり歯ごたえ十分な問題を用意したので、じっくり取り組んで数学に対する免疫力をつけてみよう!