1991 年 7 月の』 S C 言語原案作成委員会発足から 1992 年 3 月の』 S C ドラフト作成終 了までの期間 , いかロ SO C をベースにした作業とはいえ , 多くのをクリアしな けれはならなかった。規格制定作業とは , 極言すれは文化の統一作業ともいえる。さら に』 S C ドラフトが目指したのは国際一致規格である。異なる文化の壁を乗り越えた 規格制定作業か容易であろうはすかない。本バートでは旧 0 C の日本語化作業上の問 題点をはじめ , 日本が SO / ANS に提案している多バイト文字処理機能拡張案をまじ えなから , 将来的に』 S C に影響を与えるであろ引 SO C か抱える日本語処理問題 についても考察する。 はじめに 「 C 言語規格の現状」といっても読者の方々 は , 「 ANSI C は , もう決まったじゃないか。 何をいまさら」と思われるかもしれない。確 かにそうて、ある。 米国国内規格協会 ( ANSI ) は , 1989 年 12 月 14 日付けて、「 ANSI X3.159 ー 1989 American National Standard for lnformation System s-Programming Language-C 」を認証した 実際 , それを受けて本誌て、も , ' 90 年 4 月号 , 5 月号と 2 回にわたって , ANSI C の特集が組 まれた。また , 数年前から , 各メーカー , べ ンダーからリリースされる新しいコンパイラ や C 言語関連のツール類を含めた C 言語システ ムは , ほとんどすべて「 ANSIC 対応」 , 「 AN SI C 準拠」とうたわれている。しかし , AN SIC は , あくまて、もアメリカの国内規格て、あ 一方 , これは , あまり知られていないよう て、あるが , 国際標準化機構 ( ISO ) て、も , 1990 年 12 月 15 日付けて TINTERNATIONAL ST ANDARD ISO/IEC 9899 : 1990 (E) Progr amming Languages-C 」が認証されている。 ISO C の内容は , 章節番号などのドキュメン 36 C MAGAZINE 1992 6 トとしての体裁が ANSI C と異なっているだ けて、 , 「技術的」には , ANSIC とまったく同 一て、ある ( 余談て、あるが , ANSI C 規格原案 は , troff 書式て、作成されており , ISO C の規 格原案は , その troff のマクロに修正を加えて ISO 流にしたものて、ある ) 。 このように , ISO C と ANSI C とが同一な のは当然て、 , ISO の C 言語作業部会 (SC22/W G14 ) は , ANSI C が , 米国国内規格としてだ けて、はなく , 国際規恪としても通用するよう に , ANSI の C 言語作業部会 ( X3J11 ) の仕様原 案作成に協力してきたのて、ある。このように して取り込まれた国際化仕様には , 「 3 文字表 記」 (trigraph sequence) , 「地域化」 (localiza tion) , 「ワイド文字」 (wide character) などが ある。 また , 現在て、は , このように , ANSI C, ISO C とも同一仕様て、あることから , これら をまとめて「 the Standard C 」と呼ぶのが一一般 的になっている。 実際 , 「 X3.159 ー 1989 」の代わりに , 「 ISO 9 899 : 1990 」をそのままのドキュメント形式 て、 , 米国国内規格として採用することに , X 3J11 の内部投票て大多数の委員が賛成してい る。事務手続きて、手間取っているようて、ある が , 名実ともに C 言語規格が統一されるのは 時間の問題て、ある。 野田誠 (SC22/C WG 幹事・ JIS c 言語原案作成委員会幹事 ) さて , ISO C が決まったからには , 次に気 になるのが日本工業規格 ( JIS ) て、あろう。 1991 年 7 月 , 日本電子工業振興協会 ( 電子 協 ) は , 通産省エ業技術院 ( 工技院 ) からの委 託を受け , JISC 言語原案作成委員会 ( 委員長 は桜井弘之氏 ( NEC ) ) を発足させた。一般的 に , JIS 規格原案作成は , すべて電子協が行 っている , というわけて、はなく , 標準化に関 連している諸団体に , 工技院が JIS 原案作成 を業務委託するのが普通のようて、ある。 C 言語に関して電子協が JIS 規格原案作成 を行うことになった理由は , 以前から電子協 内部にあった言語標準化専門委員会 ( 平成 2 年度 ( 1990 年 ) て、活動を終え閉会された ) が , X3J11 発足 ( 1983 年 ) 当時から , X3J11 が作成 した ANSIC 規格原案をフォローし , JIS 化 を意識した和訳を行ってきていたという実 績があったからて、あろう。この言語標準化 専門委員会の ANSI C 訳は毎年 , 電子協から 「調査報告書」として発表されている。 また , JIS 原案作成のための委員会は , 「メ ーカーサイド」 , 「ユーザサイド」および「中立」 の立場の人達から構成されるのが一一般的なよ うて、ある。 JISC 言語原案作成委員会も一応 それを考慮して委員構成された。 この委員会の発足は , 1991 年 7 月て、あった が , 実際の作業は翌月から開始された。これ は , 委員が所属している各メーカーの夏期休 瑕がまちまちて、あり , うまい具合に 7 月中に 委員会開催の調整をつけることがて、きなかっ たからてあるにれはまったくの余談 ) 。 そして , その作業期間は , その空白の 7 月 日本国内規格

れているのて、すか ? どのくらい進んて、いま すか ? 」などといった具合て、す。これは非常 によいことて、 , もちろんよりよい標準規格を 作るのにも役立ちます。 とにかくこの分野は現在のビジネスの鍵を にぎっているのて、 , 重要視され , 激論がかわ されています。もし標準規格に正しく適合し ていないと , 販売マーケットがかぎられてし まいます。 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 と呼ばれる「標準への追加」 , つまり

保証が得られないことになる。 common initial sequence さて , 前節の冒頭て、「共用体のあるメンバ に対して値を格納し , そのメンバとは型が 異なる別なメンバの値を参照するようなコ ーディングは通常は誤りて、ある」と述べた。 て、は「通常て、はない」ケースて、は「誤りて、はな い」ことがあるのだろうか。 実は , そのようなケースがあることが定 められているのて、ある。その特別の場合と は「 common initial sequence 」と呼ばれてい る。日本語て、は「 ( メンバの ) 共通先頭部並び」 とて、も訳すべきだろうか ( なお余談だが , K& R 第 2 版の邦訳て、は A8.3 て、これを「共通初期 化部分」と訳している。 initial を「初期化」と 訳したために , A8.3 の最後のパラグラフは 何のことかわからない文章になってしまっ た ) 。 List 9 の例を見てもらったほうがわか りやすいだろう。 List 9 て、まず注目すべきは switch 文の制御 式 (controlling expression) のところて、用い ている共用体のタイプタグの参照て、ある。 switch (). sa. tag a) { が , この値が 1 の場合には共用体のメンバ sb ー含まれるメンバ tag a て、ある。ところ こて、参照しているのは共用体のメンバ sa に うテストをする場合には , 原則論からは u が すなわち , 最初の u. sb. tab b 残る。 ングするようにしても , 建て前上の問題は るいは if を使って List 10 のようにコーディ トすることにしても状況に大差はない。あ itch 文を使うかぎり , どのタイプタグをテス 共用体のメンバに属しているのて、ある。 sw のタイプタグは本当に必要な値とは異なる る。つまり switch 文て、テストしている場合 値が 2 の場合には同様に u. sc. c を参照してい に含まれるメンバ b て、ある u. sb. b を参照し , more ある。 わかっていなければならないということて、 現在保持しているメンバは sb て、あることが 代入はおそらく問題ないだろうという予想 うものてある。そう解釈すれば , これらの リに割り付けられる」ことを利用しようとい る構造体て、あったとしても同じ形式て、メモ 体の先頭から並んて、いれば , それらは異な の精神は「同じ型のメンバが同じ順序て構造 しかし , common initial sequence の本来 うのは ANSI 違反なのかもしれない イプタグに代入を行ってから値の代入を行 数 bar や baz のように共通先頭並びの別のタ いのかとも思われる。そうすると List 9 の関 検分 (inspect) て、ある以上 , 代入は許されな 分のどれを検分してもかまわない」て、ある。 ひとつを保持している場合にかぎり共通部 て、共用体オプジェクトが「それらの構造体の こて、 ANSI が規定しているのは , あくま の場合には同一の幅を有する場合 ) 。 している場合 ( およびビットフィールド メンバが整合する (compatible) 型を有 ひとつ以上のメンバに関してそれらの に「共通先頭部並び」を共有する。 なお , ふたつの構造体は次のような場合 検分してもかまわない。 ③複数の構造体に共通の先頭部分のどれを 体のひとつを保持している場合には , ②かっ共用体オプジェクトがそれらの構造 共有する複数の構造体を含んでいて , ①共用体が , それぞれが共通先頭部並びを 定を設けている (ANSI 3.3.2.3 ) 。 すぎるため , ANSIC て、は次のような例外規 しかし , この制約はあまりに杓子定規に ならないという結論が導かれることになる。 用体て、はその外部にタイプタグを置かねば これが真てあれば , List 9 に示したような共 ーディングは誤っていることになる。もし したがって , ここて、示した if 文のようなコ が立つ。 FuII Screen Editor 日本語版 第一 ef プロクラミング・エテイター日卒第新 Full Screen Ed 員 ( 消費税は含ます ) 定価 48 , 000 円 プログラミング・エテイタ ANSI C ー more 121 く資料請求番号 121 〉 TEL. 0425 ー 23 ー 4469 FAX. 0425-27- 引 27 立川事業所ューザ・サポート係 ・お問合せは東京都立川市曙町ト絽ー 2 ー清ビル 日ホシステム槽式会社 新発売 / ムヒ 新機 新機能 新機能 対応機種」一 3m0 、 J -3300 シリーズ価格 19 , 800 円 ( 税別 ) ない人でも OK / 簡単操作の能力開発ソフトウェアです。 格試験等に最適です。「ダイナブック速読」は DOS を知ら で能力がアップします。情報収集、受験、資 読書速度が 3 ~ 5 倍になり、右脳の刺激 ダイナブック速読 ただ今、とっても便利な習′ f マクロ集を公開中 ザ・サポート係までこ・連絡下さい。 方、セット販売希望の方、またサイトライセンス希望の方はユー もいたしております。・お急ぎの方、上記以外のメディア希望の ・英語 DOS では使用できませんが、 B 「 ief 英語版とのセット販売 ・ 5 ・ 2DD 、 3.5 ・ 2DD デュアルメディア・ MS ー DOS3 」以降に対応 東芝、 NEC 、 AX 協議会、旧 M 、富士通、 DOS/V 06 機種対応パッケージ C Users Journa l) アンドゥだ一 - ーおもわず間違うのを期待してしまいそうだ。 (The に不満を覚えたら、これしかない。 ( Oh / FM ) ・まるで夢のような 300 回のアンドウは大きな特徴。 ( 日経バイト ) ・既存のエデイタ ない。 (Jerry Pournelle/BYTE) ・ソフト開発には強力なツール、 ・プログラミング向きェデイタを探している人は、もう探す必要は アメリカでも日本でも高い評価 ョン ) 、メニュー ( オプション ) etc. 数を拡張、リジューム機能、 ctrl キー・アサイン ( オプシ キー操作のファイルへのセープとリプレイ、処理可能行 ・その他の主な新機能 切れても安心です。 容をファイルに自動保存します。だから編集中に電源が Brief は、一定時問、キーを操作しないと最新の編集内 ・安全編集 ます。 ますので、やり直しの面倒を気にせず、安心して編集でき 各ファイルこ・とに 3 圓までの操作を元にもどすことができ ・ 300 回ものアンドゥ 構文を自動生成します。 C 、 Ada 、 Basic 、 COBOL 、 FORTRAN 、 MODULA2 、 Pascal で く構文の自動生成〉 ・テンプレート機能 トやウォッチ・ドッグもセットできます。 ソースコードでデバッグできます。もちろんプレークポイン ・マクロのスクリーン・デパッガ 簡単でカスタマイズも思いのままです。 使い慣れている C 言語でマクロが組めますから、習得が ・ C 言語で組めるマクロ

さのない厳密な仕様にしなければならない そのような観点て、 , この下訳を見直してみる とかなり手直しを施さなければならないこと がわかったのて、ある。 まず , いちばん時間を取られるのが , 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 として共同作業を行っている

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

第 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

引 mo Fig. 8 List 7 の LSI C -86 ve 「 3.3 による実行結果 1 .000000 00 00 80 3F 1065353216 1084227584 5 ℃ 00000 00 00 AO 40 9.000000 00 00 10 41 1091 567616 1095761920 1 3 ℃ 00000 00 00 50 41 1099431936 17.000000 00 00 88 41 00 00 A8 41 1 101529088 21 ℃ 00000 1 103626240 25.000000 00 00 C8 41 00 00 E8 41 1 105723392 29 ℃ 00000 33 ℃ 00000 00 00 04 42 1 107558400 もっとも , このため JIS-Pascal の文法の 己述が難解になってしまっているという指 摘があり , 論理的には C 言語のように単純に 入れ子にしたほうがすっきりする。ところ が , 見た目と論理というのは必ずしも一致 してくれないのが世の常て、あって , やはり C 言語のこの書き方はわずらわしく感じられ その問題の使い方とは , 一般にオーバレ そのまま integral (integral は char, すべての C 十十や一部の C 言語処理系て、はこの点が int, および enum の総称 ) として取り出した イ (overlay) と呼ばれるものて、ある。 List 7 ANSI C に対して拡張されている。すなわち 「無名共用体 (anonymous union) 」という機 値」を得たいのて、ある。このような目的には を見てほしい。この例て、は , 共用体の各メ オーバレイというのがひとつの有効な手段 能て、あり , これを用いる場合 , List 6 に示す ンバが重なり合ってメモリ上に割り付けら て、ある。 ように , struct の内側の union には , その un れることを積極的に利用している。すなわ LSI C ー 86 ver 3.3 による List 7 の実行結 ち , float の変数 f と char の配列 b, および 10 ion 自身に対する名前を与えない。そうし 果を Fig. 8 に示すが , 1 行の左端に float の変 ng の変数 n を同じメモリに割り付けること て , この場合のメンバ n のアクセスには , s 数の値が実数形式て、表示され , ついて、それ て、 , f の値をバイト単位てるを通じてアクセス が f00 型のオプジェクトて、あるとすると s. n と が内部的にはどのようなビットパターンと て、きるようにし , さらに f の値を long の整数 書くことがて、き , PascaI と同じになる。 して記憶されているのか , いわゆる内部表 の機能は ANSI C には含まれていないのて、 , としてもアクセスて、きるようにしているの 現形式がバイト単位て、表示される。さらに 残念ながら C 言語を使うかぎりわずらわしく て、ある。 同じビットパターンをそのまま long として ても中間の共用体名を省略することはて、き これはいわば , C 言語の型システムの裏を 解釈したらどのような値になるかが右端に かいているのて、ある。 Pascal て、も同様のこ ただし , マクロを利用して逃れるこ 表示される。 とがて、きる。実際 , C 言語よりもはるかに型 とは可能て、ある。 List 7 の実行結果は明らかに処理系や使 にうるさく , かつ自由なキャストや , 任意 なお , C 十十の無名共用体はここて、示した 用している CPU のアーキテクチャ , あるい の変数のアドレス値を取ってポインタにす 用途以外の意味も持っているのだが , C 十十 は , 場合によっては浮動小数点演算ハード る操作などが許されない標準 PascaI におい に対するこれ以上の深入りは避ける。 ウェアがあるのかどうかなどの環境にも左 ては , オーバレイが型システムの制約を逃れ ーバレイ るための唯一の手段て、あった。通常 , C 言語 右されることになる。 ・・・型システムの裏をかく なお , List 7 の動作説明は , 暗黙のうちに て、 float の変数の値を long として取り出すた float と long のサイズが同じてあることを仮 めに ( long ) て、キャストしたり , long 型の変 前節まて、において , 共用体の基本的な用 数に値を代入したりしても , それは「 float の 定していることを注意しておきたい。 float 途はおのおののメンバが排他的に使用され と long のサイズが異なる環境て、は , このプ 値を ( なるべくその値を保つように ) 型変換 る場合て、あると述べた。共用体のあるメン ログラムの動作は若干変わる。 sizeof(floa して long にした値」が得られるだけて、ある。 バに対して値を格納し , そのメンバとは型 t) >sizeof(long) の場合には float の一部だ 普通はそれが望ましい動作て、あり , 何も が異なる別なメンバの値を参照するような けが long として解釈され , sizeof(float) <s 問題はない。だが , ときとして「内部表現を コーディングは通常は誤りて、ある。ところ 知りたい」というような要求が生まれること izeof(long) の場合には long として解釈する が , あえてそのような使い方を用いるケー メモリ内容の一部には初期化されていない がある。そのような場合にはデータを 1 ビッ スがあることは触れておくべきだろう。 ト単位て、取り出す必要がある。これにはビ あらかじめ注意しておくが , ここて、述べ バイトデータが含まれていることになる。 ット演算を用いることがて、きよう。ところ このように共用体を用いてオーバレイを実 るような共用体の使い方をした場合には , がビット演算の演算子い , & , は integra 現すると , ビットパターンを保ったままて その結果は処理系に強く依存する。移植性 を高くしたいならばこのような使い方は避 1 にしか適用て、きない (ANSI 3.3.10 ~ 3.3. まったく違う型としてアクセスする ( 解釈す る ) 作業をエレガントに記述することがて、き 12 ) 。そのため , 「 float のビットパターンを けるべきてあろう。 1 三ロ ANSI C ー more 119

C 概観 いか明確になっていない このように , 現在の the Standard C て、の多 バイト文字処理 ( 日本語処理はその特殊な場 合 ) を行うには , まだまだ間題点が山積して 現在 , ISO C の作業部会 WG14 て、は , the S tandard C に対する「補遺」 (Normatinve Ad dendum) を作成している。この Addendum は , 次にあげる三つのパートに分かれてい ・現仕様の更なる明確化 ( イギリスの提案 ) ・ 3 文字表記法の改善案 ( デンマークの提案 ) ・多バイト文字処理機能拡張提案 ( 日本の提 各提案の詳細な説明は省略するが , この A ddendum は順調に行けば 1993 年中には ISO レ ベルて、正式に登録される予定て、ある。また , この Addendum は , X3J11 て、も正式な提案と して検討されることが合意されており , WG 14 と X3J11 との合同国際会議て、検討されてい る。なお , 多バイト文字処理機能拡張仕様案 ( MuItibyte Support Extensi ons, 略して M SE という ) は , 日本の SC22 / CWG がテクニ カルエデイタになっている ( 本特集 PART 1 参照 ) 。 歴史をひもとけば , ワイド文字の概念の導 入は , 1984 年に発足した日本語 UNIX 諮問委 員会て、の検討にまて、遡ることがて、きる。日本 語 UN Ⅸ諮問委員会は , 当時の AT & T ュニッ クスパシフィック社の諮問を受け , 日本語を 扱える機能を取り込んだ UNIX の検討を目的 として , 東京大学の石田晴久氏を委員長と し , メーカーなどが参加して発足した委員会 Normative AddéR um ノト文字処理機能 拡張提案 ( MSE) 以下に , この MSE を簡単に紹介しよう。 MSE 作成の背景 て、ある。これ以降 , C 言語における多バイト 文字機能をはじめ , UN Ⅸの国際化機能は , この委員会の答申が基盤になっている。この 委員会発足以降 , Fig. 9 に示すようなプロジ ェクト , 委員会が発足し , 国際化機能を議論 し始めた。 このように , さまざまな団体て、似て非なる 仕様が作成されていったが , 国内て、も確固た る実績を持ち , デファクトスタンダードとな るに足る仕様は出現しなかった。 Fig. 9 のい くつかの委員会から , X3J11 に , 多バイト文 字を扱うライプラリ群の提案が何回か行われ たが , 当初は , 実績がない , という理由て、あ まり積極的に検討してもらうことがて、きなか った。 ANSI C の仕様自体が , ' 87 年頃には すて、に固まってきており , 前記のワイド文 字 , および mb 系基本 5 関数を追加することが 精一杯て、あった , というのが実情のようて、あ る。 その後 , 国内外て、乱立している多バイト文 字処理ライプラリを統合し , より完全な形 て、 , ISOC/ANSIC に提案を行うべく , 198 9 年 , 情処学会 SC22 / C WG の下に , 多バイト 文字処理検討サプワーキンググループが設け られた。このサプ WG て、は , 可能なかぎり , 各種関連団体から関係者に参加してもらい , 当時 , 世の中に発表されていた仕様 , あるい は検討中の仕様を網羅し詳細な検討を加え , 全体的にコナセンサスが取れた共通仕様を抽 出した。 1990 年 1 月 , このサプ WG て、作成された多 バイト文字処理提案は , ISO SC22/WG14 に 正式に提出され , ISO C の Addendum 案の一 部として議論されるよになった。 また , 現在て、は , X / Open をはじめ各標準 化関連団体は , 多バイト文字処理ライプラリ に関しては , この ISO SC22 / WG14 の仕様を 採用しており , WG14 の作業と同期を取り , 協力しあいながら仕様案の検討を行ってい る。さらに , ANSI の C 十十委員会 ( X3J16 ) て、も , この多バイト文字処理ライプラリを C 十十における I/O ストリームライプラリとし て取り込むことを検討している。 MSE の内容 特集第 3 の標準』 S C 概観 45 格厳密合致プログラム」て、 , すて、に , MSE の になっているのて、ある。すなわち , 現状の「規 ューザが使用可能な名前空間を侵さないよう じ込められている。 こうすることによって , ァイル < wchar. h > の中に関数原型宣言が閉 MSE のライプラリ群は , ひとつのヘッダフ MSE て、は未解決て、ある。 ストリーム , 複数文字集合の問題も現段階の すべてクリアされているわけて、はない。複数 the Standard C て、の日本語処理上の問題点が しかし , 残念ながら , 前述したさまざまな ード系に対しても十分な考慮が払われてい る。とくに , シフト状態に依存するようなコ 能なように検討が加えられ仕様作成されてい どのような文字コード体系て、あっても実装可 さらに , MSE のライプラリ群は , 処理系が るようになっている。 置き換えるだけて、 , 多バイト文字処理カイき 対して , 原則的には , 単純にライプラリ名を ト文字べースのテキスト処理のプログラムに を形成している。したがって , 従来の 1 バイ ヾイト文字べースのライプラリとのアナロジ また , これらのライプラリ群は , 既存の 1 な規定を設けることだけが許されている。 efined behavior) となってしまう部分に新た um て、は , 現仕様の中て、「未定義の動作」 (und いい換えれば , Addend なければならない 密合致プログラム」がそのまま受け付けられ 仕様を実装した処理系て、も , 既存の「規格厳 ることは許されない。つまり , Addendum の 仕様」て、あるから , 既存の仕様に変更を加え ただし , Addendum は , あくまて、も「追加 の機能をサポートするのて、ある。 が等しいワイド文字に変換して処理するため イト文字のままて、はなく , 各文字のバイト数 これは , あくまて、も , 文字列データを多バ 加する。 て、処理を行うための完全なライプラリ群を追 に修正を加えることなく , ワイド文字べース MSE て、は , 現状の the Standard 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 メン / ヾ

もありますが , 配列式処理や並行処理サポー トなどの分野て、はまだ間題が未解決のまま て、 , いまだに試行錯誤が続いています。 これら以外の , 複素数演算などの分野は比 較的よく理解されています。この「テクニカ ルリポート」がそのまま新しい標準になるこ とはありません。しかし数年後に行われるこ れらの事項の追加・検討・分類の際 , つまり 最初の見直し時には , この報告書が有効なガ イドラインにはなるて、しよう。 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)