もありますが , 配列式処理や並行処理サポー トなどの分野て、はまだ間題が未解決のまま て、 , いまだに試行錯誤が続いています。 これら以外の , 複素数演算などの分野は比 較的よく理解されています。この「テクニカ ルリポート」がそのまま新しい標準になるこ とはありません。しかし数年後に行われるこ れらの事項の追加・検討・分類の際 , つまり 最初の見直し時には , この報告書が有効なガ イドラインにはなるて、しよう。 C 十十の標準イ 最後に C 十十に話題を転じます。 C 十十の 標準化て、は , C の標準化とは少しばかり事情 が違っています。つまりすて、に C を標準化し た経験があるのて、 , そのときよりは簡単に そしてもっと時代に対応した標準化を試みる ことがて、きるはずて、す。 ごく初期の段階て、 , C 十十標準の作成は A NSI の委員会て、はなく , ISO の委員会て、行う べきて、 , そこて、内容の細部を定めるというこ とが決定されました。そうして ANSI の委員 会て、ある X3J16 と ISO の委員会てある WG21 委 員会が , すべてのミーティングを合同て、開 き , ANSI と ISO の両標準を同時に作成・制 定することになったのて、す。 こうすることにより標準作成のために必要 な期間の短縮が期侍て、きるて、しようし , 少な くとも議論が単純かっ最小限になるだろう と , 私は期待しています。ただし , 解決すべ き課題は多くあります。 C の標準化作業は ' 83 年に始まりました。 の ' 83 年に強く感じたことは , 標準を短期間 に作成しないと世界の速い動きについていけ ないだろうということて、した。そして作業を 懸命に進め , その結果 ' 85 年に公式のレビュ ー (formal public review) 用のドキュメント が完成しました。このドキュメントは現在の C にきわめて近いものて、したが , C 言語の正式 な標準化まて、にはさらに 5 年近くを要しまし た。て、も , 言語自体の標準はこの ' 85 年 4 月に はほとんど完成していたのて、す。 つまりその後の 6 , 7 年は試行のための期間 とも考えられます。そのため標準制定からま だ 2 年ほどしか経過していないのに この標 準は実によく知れわたっています。 C 十十にもだいたい同じことが起こるだろ うと , みなさんは感じておられることて、しょ う。実際 C 十十の最新バージョンて、の例外処 理やジェネリックタイプなどのサポートにつ いては , たいていの意見が一致しています。 しかし C 十十の完全な標準化にはまだまだ何 年もかかるてしよう。というのも , 解決すべ き技術的な問題や言語仕様としての曖昧さな どがまだまだ多いからて、す。 すて、にご存じかもしれませんが , この標準 化のなかて私が興味を抱いているのはライプ ラリて、す。少なくともライプラリの分野に関 しては , レビュー用のドキュメント作成がほ とんど行われていません。て、すから私も ' 92 年 3 月のロンドンミーティングからアクティ プな参加を再開し , そこて℃十十のライプラ リにどのようなことが望まれているかを理解 したいと思っています。そして , それが私の 個人としての目標て、ある C 十十のライプラリ の開発や , それについての説明などにも役立 っと思います。 C 十十の標準化についてはには 2 通りの見方 があります。つまり「何年もかからないと C 十十 標準がて、きない」という見方と , 「確かに時間 はかかるが , すて、に見通しはついている」と いう見方て、す。どちらの見方を取るかは , 標 準化に対して楽観的て、あるか悲観的て、あるか によるて、しよう。これについてどのようにお 感じになりますか。 開発が完了するわけて、はありません。そうて、 C の標準化によって C 言語をエンハンスする C 言語が主人公 いましばらくは 越えなければなりません。 多く , 詳細について決めるという困難を乗り いずれにせよ , しなければならないごとは C 概観 [ 注 ] ことて、す。 語て、あり続けるのは , 私の経験から確実な のて、す。て、すから , ここ数年は C が重要な言 C に対する注目のほうが , まだすっと大きい ほど顕著て、はありません。世界的に見ると 広がっているめ , その社会への侵入もそれ しかし , 現在の C 社会があまりにも大きく す。 一方 , C 十十は重要な C からの派生言語て、 だけのことて、す。 化し , そのためのプラットホームを提供する はなく , 単に ( プログラミングの ) 方法を標準 特集第 3 の標準』 S C 概観 35 ( 6 ) 前述の最初の見直しが見込まれている年 拡張を意味しているのだろう ( 5 ) 一般には方言のことて、あるが , ここて、は ( 4 ) 配列同士の代入や演算などを指す I と N の間の文字数を示している。 数から 118N と略されている。この 18 は 単語があまりにも長すぎるのて、 , 文字 は internationalization のことて、 , この というものて、ある。なお , 「国際化」と 示・印字することも簡単になるだろう , て、普通の C ソースを ASCII と同様に表 が扱えるようになるのて、 , デンマーク コンピュータシステムて、簡単に多国語 化」プロジェクトがひと段落し , 多くの れる。つまり , 数年後には各種の「国際 な彼の期侍に基づいているものと思わ , こて、の PIauger 氏の話は , 次のよう たものと考えられる。 制定の動きなども , この「国際化」に沿っ られる。 X Window や新しい文字コード ざまな分野て、「国際化」への取り組みが見 ( 3 ) 現在コンピュータシステムに関するさま などの文字のこと れる不変コード集合には含まれない、、 { 〃 ( 2 ) ASCII には含まれるが , IS0646 て、規定さ ことて、ある C が制定された ' 89 年 12 月からの 5 年間の こて、いっている 5 年間とは , ANSI の (I)

れているのて、すか ? どのくらい進んて、いま すか ? 」などといった具合て、す。これは非常 によいことて、 , もちろんよりよい標準規格を 作るのにも役立ちます。 とにかくこの分野は現在のビジネスの鍵を にぎっているのて、 , 重要視され , 激論がかわ されています。もし標準規格に正しく適合し ていないと , 販売マーケットがかぎられてし まいます。 C の標準化に関する ANSI 委員会の昨年の 活動にはほとんど見るべきものがありませ ん。昨年の 5 月にマサチューセッツのローウ ェルて、一度だけミーティングがありました が , 私は出席て、きませんて、した。 ' 91 年 11 月 にミラノて、行われる予定だった X3J11 の ( ISO とのジョイント ) ミーティングには , メンノヾ のアメリカ人があまり集まらなかったため , 正式な開催にはなりませんて、した。そのた め , このミーティングは ISO だけのミーティ ングになってしまいました。全体としては , ANSI の標準と ISO の標準はほとんど同じもの て、す。再検討しなければならなかったルール もほとんどなく , 文書形式やセクション番号 など変更はわすかて、した。 しかしまだいくつかの問題が残っていま す。現在 , 私たちは , 公式に ISO 標準を AN SI 標準として採用する過程にあります。技術 的には問題もなく , たいしたことて、はなかっ たのて、す。しかし手続き上て、正しいルールに 従わないところがあったため , 思ったよりも 長く時間がかかっています。て、もきっとこれ は実現されると思います。その結果 , もっと 全体的なシステム構築が楽になっていくはず て、す。 さて , 昨年 ANSI の X3J11 委員会が行って ことは , ほとんど標準規格の解釈だけて、 す。つまり質問を受け付け , それに回答する ことて、す。昨年来日したとき , 私がそれまて、 に受けた解釈に関する質問のうちいくつかの 例をあげました。て、も , そのなかて、標準に対 して重大な挑戦となるものはほんのわすかて、 した。多くの質間は「これは正しそうだが , ちょっと疑間がある。あいまいだし , よくわ からない」という類のものだったのて、すが , それらの質問が悪いて、きだったとは少しも思 いません。 ただ , X3J11 委員会の活動が衰えてきてい るのは確かて、す。数年前まて、は 1 週間のミ ティングが 1 年に 4 回開催されました。それが 今て、は , たぶん 1 年に 2 回て、 , 開催日も 3 日間ぐ らいになっています。解釈に割く時間も少な くなりました。ちなみに次のミーティング は , 今年 5 月にソルトレイクシティて、行われ る予定て、すが , それも ISO のグループと合同 て、行われます。 私が昨年のこのミーティングて、も述べたよ うに ,ANSI の C があと数年変わらないのは確 実て、す。 ANSI のルールに従うと , 5 年間 ( 1) は 待たなければならないはずて、す。この 5 年間 に最新バージョンを出して人々の関心を留め ておくということは許されません。つまり , この 5 年間は何も実質的な変更をせすに待た なくてはならないのて、す。 そして 5 年が経過したところて、 , 「この標準 を修正して使用しますか ? それとも , 標準 なんてもう必要ないのて、 , この標準を廃棄し ますか ? さあ , どちらにしましようか ? 」 となるのて、す。そこて、修正しようと一度決め たら , また多少の時間がかかるて、しよう。し かし , 少なくともこの 5 年間て ANSIC が変わ ることはないのて、す。 X3J11 委員会から出さ れるさまざまな解釈は , 説明したり改善に向 けてのガイダンスには役立ちますが , それが ANSI の C を変えることは決してありません。 C に関して , ANSI の活動が衰える一方て、 , ISO の活動がますます活発になったのは興味 深いことて、す。私たちは現在 1 年に 2 回ミーテ イングを開きます。いや , 3 回ぐらいかな。 そして 1 回の開催期間も 2 日間から 3 日間に変 わりました。私たちは ISO て、の仕事をどんど ん進めていきます。 私たちは 2 年前に認められた Normative 国際標準への機能追加 C 概観 特集第 3 の標準』 S C 概観 33 あらゆるアプローチを普遍的に実現する方法 じというものもあります。てすがいまだに には , 少しだけ異なっていて , ほとんどは同 に多数の規格案が提出されます。そのなか た。しかしこれに対して , 今て、も数か月おき ても , もっと簡単に C が書けるようにしまし なヨーロッパのアルファベットを使ったとし そこて、 , C を少しだけ変更して , さまざま と主張しています。 らはこの問題を解決するための追加が必要だ にくいものになってしまいます。そのため彼 ますが , この 3 文字表記を使うとさらに読み 3 文字表記という機能を使うようになってい ANSI 規格て、はこのような文字に対しては たいへん見づらくなります。 使ったプログラムをプリンタに出力すると , なってしまうからて、す。こういった文字を アクセントマークなどのもっと変な文字に 使いますが , それがデンマーク語になると , ラムを書くのにはたくさんの変な文字 ( 2 ) を はよく理解て、きます。というのは , C プログ が書けないと考えています。これに関して リンタて、きれいに出力て、きるような C ソース 第二に , テ。ンマーク人はデンマーク製のプ 何も変更しないということて、す。 題て、す。英国の提案の意図は , 現在の標準を これはずっと , 気をつけなくてはならない問 しないかの説明には細心の注意が必要て、す。 変更することなのて、 , 何を変更して何を変更 ところて、「標準への追加」は , 公的に標準を となのて、す。 て、はなく , もっと明確にしてほしいというこ す。これは標準そのものの意味を変更するの し , その結果を文書化したいと考えていま 彼らは「未定義の動作」などをきちんと解釈 はとくにはっきりさせたいというものて、す。 て、 , 「未定義の動作」と呼ばれるものに関して っとはっきりと C の標準は説明されるべき そのひとつが英国から出されたものて、 , も 更には大きな仕事が三つあります。 業を進めていくことになっています。この変 C に対して ISO のメンバが必要と思う変更作 Addendum と呼ばれる「標準への追加」 , つまり

第 3 の標準 J ト C 概観 五ロ ら 致した国際一致規格であること は容易に推測できる。本特集で は』 S C の原典となった旧 0 C への追加提案 (Normativ e Addendum) や JIS C ド ラフト作成問題点をとおし て』 S C の姿を浮き彫りにす るとともに , 国際一致規格に合 致した C プログラム証につ いても考察する。 1992 年 3 月現在 , 旧 0 / 旧 C 9 899 : 1990 を原典とした J 旧 C 言語原案作成委員会による JIS C ドラフト作業は終了し た。 1972 年 , C 言語の登場から 20 年の時間を要して , 待望の J 旧 C ( 日本工業規格 C 言語 ) が 誕生しようとしている。いうま でもなく , 今後登場する』 S C は AN 規格 , 旧 0 規格に合 P. J. Plauger ( ANS は 3J Ⅱ委員会書記・に 0 WGI 4Convenor) / 監訳・福富寛 ANSI C&ISO C の今後 PART 1989 年 AN 日規格 , 1 990 年旧 O 規格 , それそれの制定をみたのちに』 S C ドラフト作業 があまりありませんて、した。しかし , 現在て、 か開始された。このタイミングか意味するところは , いすれ制定されるであろう』 S C はアメリカ人よりも日本人のほうが標準化に に国際一致規格としての性格を持たせることを狙ったものと解釈できる。』 S C は旧 関して , より深い認識を持っています。 0 C(ANSI C ) の完全日本語化といわれているか , 旧 0 C には現在 NO 「 mative A というのも , こ数日会った日本人は皆 , ddendum と呼ばれる追加仕様か提案されている。本ノヾートでは AN 日 X3J11 委員会 口をそろえて「私たちは ISO の標準に適合すべ きだ。日本の標準てはなく , ISO に ! 」といい 書記ならびに旧 0 WGI 4 委員会の Conveno 「を務 P. J. Plauge 「氏に No 「 m ative Addendum の現状と将来的な ANSI C, 旧 0 C の拡張について語ってもら ます。そうすれば , ヨーロッパにもアメリカ った。なお , 本ノヾートでの P. J. 曰 auge 「氏の論説は去る 2 月に開催された「株アドバン にも , 世界各国に販売て、きますよね。これは スド・テータ・コントロールズ設立 10 周年記念 OSIJ ミーティング」における同氏の講 たいへんよい姿勢だと思います。今て、は日本 演「 C / C 十十 LANGUAGE STATIJS 日 EPO 日 T 」を抜粋収録したものである。 人の標準化に対するプレッシャーや情熱が変 化してきたのが理解て、きます。 こ 10 年ほどの間に標準化について大きな 10 年前て、あれば , 「標準なんて必要ありま 変化が起こり , 標準化作業が非常に重要なも せんよ。たとえ標準がて、きたとしても , それ のとなりました。かっての産業界て、は , 標準 が気に入れば検討して使うだけて、すよ」とい 化というものがビジネスに役立っという認識 われたものて、した。それが今て、は , 「何をさ ANSI&C 標準化 32 C MAGAZINE 1992 6

はありません。これは簡単には解決て、きる問 ダイアレクト ( 5 ) を開発したり使ている人が 集まり , それらを極力標準的なものにそろえ 題て、はありません。なかには解決する必要な どないと思っている人さえいます。 ようというものて、す。 この問題が最終的に解決されるころには , たとえば , C て、複素数演算を記述する方法 この問題に悩まされるコンヒ。ュータシステム が 5 通りもあったとしたら , 誰も喜ばないて、 や端末自体が存在しないのて、はないて、しよう しよう。それよりも , それらを比較検討し標 準的なひとつの方法に絞ることのほうが望ま な文字集合 ( 3 ) は重要な課題になっているから しいて、しよう。そしてその後の数年間に複素 て、す。この大規模な文字集合も重要なプロジ 数演算が必要な人全員て、そのひとつの記述方 ェクトのひとって、す。そうて、す , 三つめのプ 法を試行してみるのて、す。 ロジェクトはみなさんもよくご存じの日本の 試行が終わる頃 , おそらく ' 95 年 ( 6 ) あたり 漢字のような大規模な文字集合を扱う機能を て、しようが , 「さあ , 標準をどのように変更 サポートすることて、す。これは日本からの提 しましようか」というときになって , それま 案て、す。 て、の数年間の豊富な試行経験が生きてくるの ANSI て、 C の標準が作られたときには , 日本 ものを追加することになります。て、すから今 て、す。つまりそれらの経験をベースに , 「 c て、 の標準化団体からの要求もあったのて、 , 漢字 書いているプログラムもそのまま使えるの も複素数演算が必要だから , そのスタイルを にかぎらす大規模な文字集合をサポートする て、 , プログラムを変更する必要はありませ 取り込みましよう」とか , 「これまて、 4 年ほど ために最小限必要な機能を取り込みました。 ん。新しい機能を利用したいときだけ , その 複素数演算を試行してきたが , 複雑なわりに 機能を追加記述すればよいのて、す。このよう この取り込みは一応うまくいったように見 は使う人がそれほどいないようだ。だから断 な変史スタイルの実現が完璧て、はなくても , 念しよう」という判断が簡単にて、きるように えましたが , 実は多くの人にとってそれ以上 の機能が必要だったのて、す。たとえばワード 極力努力しています。 なるのて、す。 プロセッシングやテキストプロセッシングな 以上が , 今 , 標準化の場て、公式に行われてい 最終的な決定はどのようなものになろう ど大規模な文字集合を扱うプログラムを書く ることて、す。これは先ほど述べた ANSI 標準の と , 数値演算に関しては , わずかしか違いの 人にとっては , 最小限の機能て、は足りなかっ 最初の見直しまて、の 5 年間に , ISO 標準に対し ないさまざまな方法をさまざまなグループて、 たのて、す。そこて、日本から多くの追加機能を て行われる変更のあらましにもなります。 試みるより , てきるだけ多くの人が同意て、き 詳細にいたるまて、うまくまとめた規格案が提 る共通な方法を全体て、試みるほうがよいて、し 案され , 現在はそれを改善中て、す。 よう。これが NCEG の根本的な目的なのて、 目標は次の 5 月のミーティングて、す。そこ す。つまり新しい C に要求されるて、あろう各 て、このような三つの要素を原案としてまと 種の拡張機能に対して , 非公式て、はあるもの 別の作業グループ , 今て、は X3J11.1 委員会 め , ほんとうに有効なものを作りたいと思っ の , 今後数年間の ( 試行のための ) 標準を見つ と呼ばれる公的な団体も標準化委員会の一部 ています。 5 月のミーティングて、 , 本当にて、 け出すことなのて、す。 として活動しています。このグループはかっ きるかどうかわかりませんが , 近づいてはい Dennis Richie もこのグループて、アクティ て NCEG ( NumericaI C Extensi on Group) ます。もして、きなければ , 8 月にロンドンて、 プに活躍しています。彼は c を開発したひと と呼ばれていたグループの公式名て、すが , 今 もミーティングを開きます。いずれにせよ今 りて、すが , 実際の標準化作業にはアクテイプ て、もこの NCEG が略称として使われていま 年中にはこれらの課題すべてがまとまり , 承 に参加しませんて、した。しかしこの新しい分 す。数年前からこのグループは , C を拡張 訒のための国際投票にかけられると確信して 野 , すなわち配列式処理や並列処理などの記 ロ・じ、 し , 並列処理や高速て、高度な数値処理 , そし います。その投票て、承認されれば , 来年には 述方法作成にはアクテイプに参加していま て配列式の一括操作 ( 4 ) などを簡単に行うため 標準への追加 , すなわち標準の変更がなされ す。 の方法を追求しています。そしてその結果と るて、しよう。 以上の事項が X3J11.1 委員会て、現在検討 して , 「テクニカルレポート」と呼ばれる報告 中のものて、す。この検討はすて、に数年間続い , こて、明らにしておきたいことは , この標 書を出すことになっていますが , この報告書 準の変更は , すべてて、きるかぎり現在の標準 ており , 委員会としては「テクニカルレポー 自体には強制力はありません。 への追加という形式をとっていることて、す。 ト」のドラフトを今年中に提出する見通して、 この報告書の基本的な目的は , 新しい C の つまり , 現在の C 標準は変更せずに , 新しい す。分野によってはかなりまとまったところ C MAGAZINE 1 2 6 X3J11.1 委員会の霑動

これて、は標準として不十分に見えるかも しれないが , 思ったよりは有用て、ある。 れを理解するには , ロケールをファイルや ファイルシステムにたとえるとよいだろう。 標準 C がファイルの特質について要求してい ることはほんのわずかて、ある。そうするこ とにより , 多様なコンビュータ上のファイ ルをプログラムからリード , ライトて、きる ようになる。 ファイル名のつけ方についても , 標準 C に はほんの少ししか規定がない。また , イン プリメンテーションが別なファイルサービ スを自由に追加してもよい 大規模な文字集合のサポートに関しても , 同様に詳細な事項と一般的な事項の組み合 わせになっている。 X3J11 は、、マルチバイト 文字″と、、ワイド文字なというふたつの概 念を導入した。大規模な文字集合を表現す る手段としては , このふたつが一般的だ。 マルチバイト文字とは , 1 個あるいは複数 個の文字 ( 訳注 : バイトのことと思われる ) の連続て、大規模な文字集合中の 1 文字 ( 訳 注 : ひとつの要素のこと ) を表現するものて、 ある。ロッキングシフトシーケンスを含む ストリング ( 訳注 : バイト列のこと ) 中にマ ルチバイト文字が存在することもある。し たがって , あるバイトの解釈は , そのバイ トの前の状態に依存する。マルチバイト文 字はシングルバイト経路を使って大規模な 文字集合を送るときに有用て、ある。このよ うなシングルバイト経路にはシリアルコミ ュニケーションラインやディスケット / ハー ドディスク上のテキストファイルなどがあ 一方 , ワイド文字は , サイズが ( 一般的には ) 16 から 32 ビットに固定された整数て、あり , 大規模な文字集合中の一要素のコードを保持 する。ワイド文字がもっとも有用なのは , プログラムて、テキストを操作する場合だ。 両方の形式にはそれぞれの使い道がある。 標準 C て、は , C ソースコード中のコメントお 14 C MAGAZINE 1992 6 よび文字列に基本文字以外の文字を使用し てもよいことになっている。このときの文 字はマルチバイト文字形式て、なければなら 実行時にマルチバイト文字形式とワイド 文字形式とを相互変換し , 変換された文字 を操作するライプラリ関数も標準 C は提供し ている。ロケール機構を使用すれば工ンコ ーディングを ( 一定の制限下て、 ) 切り換える こともてきる。しかし標準 C におけるこのよ うなガイドラインは , どのような大規模文 字集合て、も同じ方法て扱おうとするには最 小限の機能のようだ。 X3J11 は従来から使われていた 1 バイト文 字集合に対して , 特定のエンコーディング を強制していない (ASCII を使って定義して いる Ada の例もあるのて、 , 同じようにしても よかったのだが ) 。これからすれば , 大規模 な文字集合に対して特定のエンコーディン グを強制しなかったのは当然だろう。した がって , 標準 C ては大規模な文字集合のエン コード方法に対していくつかの制限が加え られてはいるが , バリエーションも許可さ れている。 だから一般的な漢字のエンコーディング すべてが使用可能なのだ。 ISO 規格として提 案中の ISO 10646 ュニバーサル文字集合はマ ルチバイトコードとして使えるだろう。ま た , 提案中 ( 訳注 : ある種の業界標準として の提案 ) の Unicode 文字集合はワイド文字コ ードとして使えるだろう。そのエンコード にとって正しくないものを表現しようとし た場合だけ , 問題が発生する。 標準 C て、の国際化アプローチにおけるおも な弱点は経験不足に由来する。それぞれの 部分部分についてはこれまて、の経験が一応 はある。しかし , それらの要素を組み合わ せたとき本当に移植性が向上するのかどう かがまだ証明されていないのだ 私は , すべてをインプリメントすること て、これらの問題を明確にしようと決めた。 programming 聞町咄 その結果として , ちょうど fThe Standar d C Library 』 (Prentice HaIl, 1992 ) とい う本を出版したところだ。 この本には , ロケールと大規模な文字集合 サポートの完全インプリメンテーションが含 まれている。マシンリーダブルなコードも入 手可能なのて、 , それを入手してコンパイルす ればアプリケーションとのリンクも可能だ。 しかもこの形態て、の利用に対してはロイヤ リティが不要てある。私としては , この本 が国際的な市場に対するコーディング実験 の活性化に役立っことを願っている。 化的適応性の良否 まて、。 最終判断がてきない。チャンネルはそのま ューザからのフィードバックがあるまて、は , い。しかしアプリケーションの作者やその ンテーションがよいものて、あるとも思いた いて私は楽観しているし , 私のインプリメ には正しアプローチしているという点につ はまだ早すぎるだろう。て、も標準 C が基本的 しても , それがうまくいくかどうかの判断 はそのほかの真面目なアプリケーションに のこのインプリメンテーションも , あるい 文化的な適応性という面ては , 標準 c も私 うまく合わないかもしれない プが提供している文化固有のサポートとも れない。またほかのべンダや標準化グルー ションからの要求に対しては不十分かもし はなんの制限もないが , 一部のアプリケー を見つけるようになっている。この方法に リがこのファイルをリードして必要な情報 がロケールの変更を要求したら , ライプラ キストエデイタて、指定可能だ。プログラム 式て、は , ほしいだけのロケールを普通のテ ケールファイルの形式を定義した。この形 こともあった。そのひとっとして , 私はロ いろいろと新たに構成しなければならない もちろん , この本を書いている途中には ,

PART C プログラム標準合致度検査 コンノヾイラか AN 日規格や旧 0 規格に合致しているかどうかを検査するには , Plum H all Validation Suite をはじめとする各種テストスイートが存在する。しかしこれ らテストスイートはあくまでコンノヾイラの規格合致度を検査するものであり , プログラ ムか ANSI 規格 , 旧 0 規格に合致しているかどうかを検査するもので一よい。 ANS い S 0 , そして』 S C と , C 言語規格カーされていく現在 , 廠密に規格に合致した C プログ ラムこそか重要となる。本ノヾートでは英国 Know dge SO 仗 wa 「 e 社か開発した C プログラム標準合致度テストスイート・ Modellmplementation fo 「 C を中心に C 言語の標準合致度検査について考えていく。 ANSI て、の C 標準化は ' 83 年に作業が開始さ れ , ' 89 年 12 月に正式な規格となった。さらに ' 90 年 12 月には ISO 規格が出版された。このふ たつの規格はセクション番号など文書形式上 には違いはあるが , 技術的内容は同じて、あ る。そのため本稿て、はおもに ISO という名称 を使用するが , 多くの場合 ANSI と置き換え ても問題はない これらの標準化作業の多くは米国て、行わ れ , かなり早い段階から多くの米国内のコン パイラベンダや一部大手 C ューザの注目を集 めていた。また日本やヨーロッパのコンパイ ラベンダなどからの注目も , 作業の後半には 高まった。このような世界的な注目のなかて、 標準化作業が行われたわけて、あるが , ら派生してきた要望が「コンパイラの標準規 格合致度の検査」て、ある。この要望はとくに コンパイラベンダからのものが強く , それに 応えるために開発されたものが PIum HaII V alidation Suite をはじめとする各種テストス ィートて、ある。 余談になるが , テストスイートという単語 に聞き覚えのない読者のために若干の説明を C 標準とテススート しておこう。テストスイートは test suite をそ のままカタカナにしたものて、ある。日本語て、 ホテルのスイートルームというときの「スイ ート」がこの suite に相当し , 一組みとか一続 きを意味する ( もっとも , 英語て、は suite だけて、 もいわゆるスイートルームを表すようだが ) 。 C コンパイラの検査プログラムの場合 , 複数 の ( 通常は多くの小さな ) テストプログラム を使うのて、 , これらの複数のテストプログ ラムー式をテストスイートと呼ぶ。これは 他言語用のコンパイラ検査て、も同様かもし れない 現在入手可能な C コンパイラ用のテストス ィートのなかにはネットワークなどから入 手て、きるフリーソフトウェアも含まれてい る。しかし実際に検査に利用してみると , フリーソフトウェアには限界があることが 簡単にわかってしまう。そのため現在て、も この種のフリーソフトウェアを使用してい るのは , 一部の一般ューザと比較記事など を掲載している雑誌社程度て、ある。 現状て、は , ほとんどのコンパイラベンダ は何らかの商用テストスイートを使用して いる。また , ョーロッパて、はすて、に英国の BSI (British Standard lnstitute) を中心と した公的な機関により C コンパイラの検査が 行われている。米国て、も NIST(National ln C 概観 福富寛 特集第 3 の標準』 s c 概観 47 ②すべての処理系に対して , 完全に同じ検 のバグも発見しやすくなる。 により , コンパイラとランタイムシステム こうすること し検査するほうが望ましい て、はなく , 何度もパターンを変えて繰り返 らに , これらの要求を一度だけ検査するの 全に区別し , 検査しなければならない。さ 動作て、ある。テストスイートはこれらを完 三つめは規格て、処理系定義とされている しなければならない ラーメッセージなり診断メッセージを出力 動作て、ある。この場合処理系はきちんと工 どの制限とされているような入力に対する ふたつめは規格て、シンタックスエラーな た入力に対する動作て、ある。 ひとつは正常な , すなわち規格に合致し それも 3 種類に分類することがて、きる。 当然ながら処理系に対するものて、あるが , するものがある。 こて、いう要求事項は , の処理系に対するものと C ソースコードに対 ISO 規格の要求事項には , コンパイラなど と ①旧 0 規格での要求事項をすべて検査するこ 必要とされる特性をここて、考えてみると , ところて、 , こういったテストスイートに テストスイートの、須条件 いは使用される予定て、ある。 のテストスイートが使用されている , ある の公的な機関による検査て、も , すべて商用 検査を開始することになっている。これら 検査検定協会 (略称は JMI) が 7 月から同様な 月から , さらには日本て、も , ( 財 ) 機械電子 stitute 0f Standards and Techn010gy) が 4 株アドバンスド・データ・コントロールズ ) (lTSCJ/SC22/C WG,ISO W 引 4 メン / ヾ

存在しているのて、ある。あるいは少なくと もその標準化はすて、に開始されている。新 しい ANSI/ISO の標準 C にそれを見出すこと がてきる。さまざまな文化への , プログラ ムての適応を真剣に打ち出した最初の言語 ヵ℃だ。 C は日本語 , 中国語 , アラビア語な どの大規模な文字集合さえ配慮している。 X3J11 は , ANSI が C 標準作成のためオー ソライズした委員会て、ある。この委員会は 1983 年にスタートしたが , その時点て、移植 性のある C プログラムを書こうとするプログ ラマに対する援助が委員会から強く表明さ れていた。文字集合非依存も初期からしば しば表明された目標だった ( IBM の代表は , ASCII だけて、なく EBCDIC も重要な文字集合 て、あると繰り返し表明していた ) 。この表明 により , ASCII の変形て、ある各種 lS0646 , つまりいくつかの異なるヨーロッパ言語て、 使用されている文字の取り込みが容易にな った。 ケールと大規模文字集合 この c の標準化過程の後半に , 文化への適 応性を C に加えてほしいという強い要望がヨ ーロッパ各国から出された。アメリカニズ ムばかりカ℃ライプラリに取り込まれていた ことが彼らの不満だった。そして少なくと もライプラリ中のアメリカふう動作だけて、 も回避したいと思っていた。異なる複数の 文化にその場て、適応て、きるライプラリを取 り込めれば最高だと考えていた。彼らはそ の両方を、、ロケール〃 ( 訳注 : 現在もっとも ポピュラーな locale の訳語。ただし英語て、の 発音には程遠いことに注意しなければなら ない ) という形態て、、達成て、きた。 そして標準化が終わろうとするころに 大規模な文字集合を C て、扱いたいという強い 希望が日本から表明された。さらにこのよ うな文字集合の扱いを将来のプログラミン グ言語標準すべてが提供すべきてある , と いう日本の動議が ISO て採択された。そのま まて、は C が大規模な文字集合サポートのない 最後の言語になったかもしれなかった。 と ころが C は大規模な文字集合サポートのある 最初の言語となれたのだ。 ロケールと大規模な文字集合は C における 重要な新要素て、ある。つまりこのふたつが C ての国際化 (internationalization) を代表 しているのて、ある ( この internationalizatio n という単語は長すぎるのて、 , 人によっては 118N と表記することもある。このときの 18 は先頭の i と末尾の n にはさまれて省略された 文字数を示している ) 。それてはこれらの要 素を説明していこう。 ロケールはある文化グループに固有の取 り決めを集めたものだ。、、ロケール〃と 語〃が同意語だと最初に思うかもしれない が , アメリカ , イングランド , そしてオー ストラリアを旅すればもっとよく理解て、き るようになるだろう。英語圏が共通言語 とに分割されているというのは本当なのだ。 私はオーストラリアの日付を今て、も ( 訳注 : 1 年間のオーストラリア生活を終えたあとに もかかわらず , という意味が含まれている ) 読みまちがう。というのも現地の人の日付 けの書き方は , 私が教わった読み方とは逆 方向なのだ。だから言語はロケールのせい ぜい一部分て、しかない ひとつの国の中て、も異なったロケールが ある。一般人の多くはマイナスの数値を書 くときに先頭に負号をつけるだけだ。しか し ( 米国の ) 会計士の場合 , 負号をつける代 わりにカッコてくくることが多い。あるい は、、 DB 〃などを後につけることもある。 またテキストのソート方法の例もある。 このソート方法くらいはわかっているつも りだと思う人も多いだろう。辞書て単語を 見つけるときには大文字と小文字の区別を 無視するのは理解しているだろう。しかし 電話帳て名前を見つけようとすると , たと えは tMcIntyre と MacWiIIiams の並べ方に変 programming 聞町咄 なルールがあることに気づくはずだ。どち らの文書も , あなたのコンビュータに組み 込まれているソートユーティリテイからの デフォルト出力とは一致しないだろう。だ んだんサプカルチャーとは何かがわかって きたのて、はないだろうカ ロケールは文字集合 , ソート順序 , 日付 形式 , 金額表現形式に関しての有用な情報 を保持している。文化間て、の相違全部をカ バーしているわけて、はないが , 多くの重要 なものを含んて、いる。たとえばテキストメ ッセージについては , それを使わないアプ リケーションを書けばいいし , そういった アプリケーションてもアイコンをうまく使 えば十分に実用になる。 しかしちょっと変わった形式の日付や金 額 , そしてソートされた名前リストを表示 しないて済ますのは難しい。というのも , 多くの人がこういう表示のためにコンヒ。ュ ータを使うのだから。だから C ロケールに れらを入れたのだ。 ルチバイト文字とワイド文字 ロケール集合には大きさの制限がない つまり , 標準 C にはロケール数の規定がない のだ。以前の C 言語やライプラリと同じ動作 が保証される C 〃ロケールが必要なだけ だ。空ストリングを名前とするネイテイプ ロケールも定義されている。これはそのコ ンビュータシステムを使う現地の人に適し ていると思われるロケールだ これら以外のロケールをいくつ追加サポ ートするかはインプリメンテーションの自 由てある。そして追加ロケールにつける名 前を何にするかもインプリメンテーション の自由だ。インプリメンテーションての実 際のロケール切り換え方法に関する規定も 標準 C にはない。標準 C が規定しているの は , ロケール切り換えが存在しなくてはな らないことだけだ。 Programming on Purpose 13

C 概観 も含めて 9 か月間 , つまり 1992 年 3 月に原案作 移植性 , および ANSI C と ISO C とが完全な JIS C 原案作成作業の 成完となることが予定された。 シンクロナイゼーションを行っていることな これは , JIS 規格原案作成作業期間として どを鑑み , ISO 9899 に対する「国際一致規格」 は異例に短いものて、ある。過去 , ほかの規格 として原案作成を行うこととした。 JIS C 言語原案作成作業とは , すなわち , 案作成作業がどれくらいの期間を要したか詳 次に , その翻訳作業の下訳として , 電子協 しくは知らないが , 1 年から 2 年くらいはかか ISO C(ISO 9899 : 1990 ) を翻訳することにほ 発行の「プログラミング用言語の標準化に関 っているのが普通らしい かならない。実際 , すて、に JIS 化されている する調査 ( 言語標準化専門委員会調査報告 C 言語に対して , これほど短期間て、の作業 プログラミング言語は , すべて , それなりの 書 ) 」 ( 平成 3 年 ( 1991 年 ) 3 月 ) の中の「 C 言語 が要請されたのは , 国内に C 言語が本格的に 対応する国際規格を翻訳したものて、ある。 ANSI 規格 ( X3.159 ー 1989 ) の訳文」を使用す 浸透してきたという状況がまず大きな要因に ることとした。 作業の前提 さて , ここて、問題が発生した。先ほど述べ なっている。 それに加えて , 前述の言語標準化専門委 たように , これはある程度 JIS 化されること 員会て、の ANSI C の翻訳が , ほとんどそのま まず問題となるのは , その対応する国際規 を意識して , 用語 , いい回し , 体裁などを J ま JISC のたたき台として使用て、きるのて、は 格に対して , 日本独自の変更や追加 , 削除を IS 流にして作成されたものて、はあったが , 完 ないか , という期待があったことも大きな 行うか否か , ということて、ある。変更 , 追 全なものとはいい難い。 JIS 流のいい回しは 加 , 削除を行わず , 完全な翻訳とする場合 , かなり独特なものて、あり , けっこう , 難しい 理由になっていた。 しかし , この目論見は , 実作業開始直後 その JIS 規格を「国際一致規格」という。 C 言語 のて、ある。また , 仮にも , 日本国内規格とし にかなり甘いものて、あることがわかった。 の場合は , 国際的な観点て、のソースコードの てプログラミング言語を規定する以上 , 曖昧 Fig. 1 C 言語規格の関連 実際 通産省 工技院 業務委託 旧 0 刀 EC 電子協 ANSI 言語標準化 専門委員会 JTC1/SC22 WG14 委員会 X3J11 委員会 JIS C 言語 原案作成委員会 翻訳版 DP9899 (Draft Proposal) X3J11/8X-yyy ( ドラフト版 ) 一流用 翻訳版 ANSI C 制定 X3.159 ー 1989 D 旧 9899 (Draft lnternational Standard) 下訳 同一内容 同一内容 JIS C 原案 旧 0 C 制定 旧 0 刀 EC9899 : 1990 特集第 3 の標準』 S C 概観 37

「 dir a: 」をそのまま呼び出せば簡単て、す。 MS ー DOS の命令を呼び出すための C 言語の関 数は <system()> て、す。これを使えば , L ist 3 の残りの部分は次のように書けます。 void format (void) system("dir a void directory (void) 学時間計測 system ("diskcopy a : void diskcopy (void) system ("format b : " ) ; 90 C MAGAZINE 1992 6 この戻り値は d 。 uble 型て、す。 て、 , これも標準ライプラリに入っています。 difftime(), a) める関数は ます。 time t 型の値 a , b の差を秒単位て、求 time t 型の値は , その差だけに意味があり とします。 a=time(NULL) ; 代入するには て、す。こうして用意した変数 a に現在時刻を time t a ・ 命令は 時刻を入れておくための変数 a を用意する と書いておかなければなりません。 #include く time. h > の最初に す。この関数を使うためには , プログラム の関数の戻り値は time t 型という特別な型て、 る関数 time ( NULL ) が備わっています。 C 言語の標準ライプラリには , 時刻を求め ムを作ってみましよう。 プログラムの実行時間を計測するプログラ こて、は とがて、きます。この応用として , ムの中からほかのプログラムを実行するこ 関数 system() を使えば , 自作のプログラ これらを使えば , プログラムの実行時間 を計測するプログラムは List 4a のように書 けます。 て、も現存のコンパイラて、は time(NULL) は秒単位の時刻を返すだけて , echo こんにちは ( 画面に「こんにちは」と表示する ) のような簡単な命令に対しては精度不足て、 す。実際には List 4b のようにするのがよい てしよう。習った命令しか使っていません が , ちょっと複雑なのて、 , 理解て、きなけれ ば読み飛ばしてかまいません。 なお , 少々込み入った話になりますが , C 言語の時間関係の関数についてここて、詳し く述べておきます。 C 言語の伝統て、は , time(NULL) は , 1970 年 1 月 1 日の午前 0 時 ( 協定世界時 ) からの経過 秒数を 1 。 ng 型 ( 32 ビットの整数 ) て、返します。 協定世界時 ( UTC ) は , 昔はグリニッジ標準 時 (GMT) と呼ばれていました。日本標準時 (JST) とは 9 時間の差があります。 なお , 32 ビットの整数の最大値は 214748 時間計測プログラム ( 簡路版 : ⅱ st4a. c ) List 5 : main( ) 3 : #include く time. h> 2 : #include く stdlib. h 〉 1 : #include く stdio. h> 4 : 7 : 8 : 9 : 10 : 11 : 12 : 13 : 14 : 25 : 24 : 23 : 22 : 21 : 20 : 19 : 17 : 14 : 13 : 11 : 9 : 8 : 7 : 4 : 15 : List double x; time_t a, b; a = time(NULL) ; system( ” ech0 こんにちは” ) ; b = time(NULL); x = difftime(), a) ; printf( ” Xg 秒 \ n ” , x) ; return 0 ; 時間計測プログラム ( 実用版 : ⅱ st4b. c ) / * double 型の変数 x を用意する * / / * time-t 型の変数 a, b を用意する * / / * 現在の時刻を a に代入 * / / * 時間計測したい命令 * / / * 現在の時刻を b に代入 * / / * 時刻の差を x に代入 * / / * x を出力 * / / * 正常終了 * / 1 : #include く stdio. h> 2 : #include く stdlib. h 〉 3 : #include く time. h> 5 : main( ) 1 ong double time t m, x, a, d; b, c; a = time(NULL); ニ time(NULL)) while (a b = time(NULL) ; while (b = time(NULL)) system("echo こんにちは” ) ; = time(NULL); C while (c = time(NULL)) d = difftime(), a) / n; x = difftime(), b) ー d * m; / * time-t 型の変数 a, b, c を用意する * / / * m ニ 0 ; n = 0 ; の略記 * / / * 現在の時刻を a に代入 * / / * 時刻が変化するまで * / / * 待っ * / / * 現在の時刻を b に代入 * / / * 時刻が変化するまで * / / * n の値を増す * / / * 時間計測したい命令 * / / * 現在の時刻を c に代入 * / / * 時刻が変化するまで * / / * m の値を増す * / / * 1 カウントあたりの秒数を d に代入 * / / * 実際の時間を推定する * / printf("Xg 秒 ( 精度 Xg 秒 )#n", x, d) : / * 正常終了 * / return 0 ;

さのない厳密な仕様にしなければならない そのような観点て、 , この下訳を見直してみる とかなり手直しを施さなければならないこと がわかったのて、ある。 まず , いちばん時間を取られるのが , JIS 流のいい回しにする作業て、ある。 JIS 規格の 書き方は , 「 JISZ 8301 ー 1990 規格票の様式」 旧流ポイント そのなかて、いちばんたいへんなのが「文章 の末尾」に関する規定て、ある。ポイントは , 「受け身を使ってはいけない」ということて、あ る。その意図は , お上が制定する規格て、ある . とする。」というように 以上は , 「 ... は , . 制定者の意図が明確になるように , ものごとを いい切らなければならない , ということて、あ . され る。」というように単に状態を表現するような いい回しはて、きない しかし , これはかなりの苦痛て、ある。最初 から日本語の文章を作文する場合はそうて、は ないかもしれないが , 英文を翻訳する場合 は , かなり難しい。しかし , これをクリアし ないと , JIS 規格として認可されないのて、あ るから , なんとか適切ないい回しを工夫しな がら翻訳作業を進めなければいけない。下訳 においても , このあたりはかなり苦労して翻 訳されている。 たとえば ISO 原文て、の受動態は , 「 .. . されなければならないものとする。」と は , . いうように訳してあるが , これて、は駄目て、 , という規格に細かく規定されている。 Fig. 2 日本語処理問題の系譜 AT&T UP JAEI. 0 ↓ JAE2.0 ↓ MNLS3.X はドキュメントの 流れ表す 旧 0 刀 EC JTC1/SC22/WG14 ANSI X3J11 C 十十 ( * ) ・ ANSI X3J16 ・旧 0 SC22/WG21 C MAGAZINE 1 的 2 6 日本語 UN Ⅸシステム諮問委員会 情報処理学会 SC22 CMG マルチバイト処理 WG ( 1984 年 ) MSE Addendum ( 作成中 ) 旧 0 C ( 作成中 ) C 十十標準規格 X3.159 ー 1989 ANSI C ↑ 旧 09899 : 1990 十 システム日本語機能 電子協 言語標準化 専門委員会 ( 翻訳中心 ) 日本 C 言語委員会 X/Open lnt'nC WG XPG4 Int'nC WG OSF lnt'nC WG JUS/SIGINT ( * ) C 十十標準規格は ANSI X3J16 委員会ど SO WG21 委員会が lnternationaltype p 「 0ject として共同作業を行っている