三田典玄の 実践 C プログラマ 養成講座 五ロ くる。電子メールシステムは今日の情報を 自然条件というものが必すある。「なぜあの ういった観点からするとなんだか理解でき ような文化になったのか」ということにつ 今日誰かに送ってくれる。 るような気がする。 IBM 流のシステムや人 最近になって UNIX を触ったユーザにとっ 間管理の方法では管理しきれないものが いて思いを巡らせることがなければ , 文化 の理解もないのは当然のことだ。そして文 てはこれらの環境がどれだけの意味をもっ UNIX にはあるからだ。カーネルは気心の知 ていることか , という認識は薄いのかもし 化の理解がなければその文化で使われてい れた数人の仲間が一心同体となっていなけ れないし , ましてや「 C マガジン」の編集部や る「道具」への理解もない。しかし , 逆に れば全体のバランスをすぐ崩してしまう。 その周辺ではどっぷりとこれらの環境に浸 の道筋を辿れば「文化を理解できればそこで カーネルという膨大な C 言語ソースコードの っている人たちも希であろうから , これは 世界はそういった「連帯」なくして理解でき , 使われている道具などについては自然とわ 仕方のないことかもしれない。 動くものではない。「 9 時から 5 時」の管理で かってくる」 , つまり達人に慣れる。私自身 私はあるメーカーの研究所のあるエンジ もそういう道筋をすべて理解できていると はバランスを崩してしまう。マニュアルに ニアとよく電子メールを使って話をする。 はすべては書かれていないから , 人間どう いうわけではない , ということだけは自分 たわいのない話だったり , 現在の秘密の しのつながりがたいへんに大きな意味をも でもよくわかる。しかし , そういった自覚 研究についてだったりする。別に産業スパ つ。膨大なプログラムがあっという間につ もない , というのではやはりある特定の文 イをしているわけではもちろんないが , も くられる代わりに , そのプログラムはつく 化の道具であるコンピュータへの道は遠い しこの話が外部に漏れたらたいへんだな , のではないだろうか。 った本人自身しかわからない。 と思うようなことも耳にすることもある。 これが UNIX の文化である。だから C 言語 news システムは joke をとばしあったりす は「行 / ステップ」では機能しないようにでき るところでもあるし , 趣味について語ると ている。つまり「ステップ」という仕事の単 ころでもあるし , 技術情報を得る ( 教える ) 位は IBM 文化のものであるから , それがき 「 C マガジン」 2 月号は UNIX の特集だった ところでもある。下手なパソコン通信顔負 ちんと拒否できるようになっているわけだ。 が , そのなかで必要不可欠なのにしつかり けの世界がそこにある。しかも , 日本で IBM 系のメインフレームを作ってい ノヾソコン 抜け落ちている項目があった。それは UNIX 通信のようにデータを読むときに電話線に る大コンピュータ会社が UN Ⅸを作ったり導 によるネットワークについてである。 入したりするとき , これらの「文化的背景」 接続されている , というわけではない。つ 現在 , UNIX を使っている人たちは , 大き まり電話料金もそうかからない。 についての理解がない ( 同意はもちろんする このネットワークは現在東エ大を中心と くふたつにわかれる。ひとつはグローバル 必要はないが ) ためにたいへんなムダや失敗 する「 JUNET 」が日本で最大規模のものであ なネットワークに加入しているユーザ , そ をしている例は私のまわりにも枚挙にいと してもう一方は加入していないユーサであ る。およそ 200 以上のコンピュータがこのネ まがない。 ットにぶらさがっている。 る。 この JUNET に接続されている小規模なネ UNIX で動くマシンでは必す UUCP という どんな文化にもそれを支えてきた歴史や ットが「 JUICE 」であり , これは JUNET をお シリアルラインを使ったファイル転送ユー ティリティが付属している。また , 最近で 手本に作られている。 こういった UNIX を中心とするネットワー はインターネット接続されたグローバルネ クについてのノウハウはなかなかマニュア ットワークもある。どちらのネットワーク ルには書いていない。つまり口コミで広が で接続されているにしても , グローバルな ったものだ。この UNIX 世界はまさに「 UNIX ネットワークに加入していなければ標準と を使っている」という感しにさせてくれる。 しての UN Ⅸを使う意味は半減してしまう。 この news と sendmail なくして UNIX は語れ たとえば X ー Window についての最新情報 , ない , といってもいいすぎではない。 バグレポートとパッチ情報などは当然ネッ トワーク経由のほうが速く MIT からやって ネットワークと UNIX 実践 c プログラマ養成講座 109

実践 C プログラマ 養成講座 三田典玄の イラスト・山形彰吾 第 - 7 回 準はそのまま日本の標準になるのが慣例だ 拠に , ポーランドも TurboC を Ver. 1.0 から から , 私たち C 言語にお世話になっている人 Ver. 1.5 へとバージョンアップするときにそ の「売り文句」として「 MS ー C コンパチ」をうた 間も , この規格のお世話になる。フレキシ ピリティがありすぎて個性豊かなバグの山 っていた。 連載もだいたい半年続くとネタ探しがた だった C 言語も , この「世界規格」でやっと一 また C旨衄が UNIX からきた言語である 「コロロ いへんである。なにせ「書く」ことよりも経 定のコーディング基準が定められるように ことを思えば , 本当の C 言語の標準は UNIX 営や開発が私の専門なのだから , ネタがな に付属の C 言語ということになる。しかし , なった。 くなるととことんなくなってしまう。 C 言語の規格案自体は 1985 年というから今 UNIX によってはこの C 言語がまったく違っ ちゃんとした「モノ書き」であればネタ探 ているものもあり , 一概にそうだともいい から 5 年も前に出されており , それに数々の しそのものが仕事の範疇に入るので , ネタ 検討が加えられ改訂され , 現在の規格案に 切れない。強いていえばマイナーではある 探しに力を入れても問題はないのだが , 私 なった。最初の規格案の作成の時点では威 が , AT&T の 3B シリーズ上の UNIX に付属 の場合は「副業」だからネタ探しのために会 勢のよかった C 言語べンダーが , ANSI に委 の C 言語が標準だということになる。 社を空ける , というわけにはいかない。 おまけに最近の UNIX では , GNU の C 言 員も出したのに実際に規格案ができあがる 今回のネタは「 UNIX と新しい C 言語とそ 語コンパイラである gcc とか , Mach を載せ 前にマイナーなべンダーになってしまった , の周辺」である。これは別に私の新しい本の などということもあったが , とにかく 5 年前 ている NeXT の Objective-C とかがでてきて 書名ではない。最近の UNIX や最近でてきた おり , とにかく「標準」と呼べるものはない。 よりもはるかにこの規格案そのものの意義 C 言語 , それにまつわる技術や文化について 「オプジェクト指向」ということであれば は大きくなったことは確かである。それほ の話題を追ってみようというのである。 ど C 言語は「生き延びた」言語だったのであ C 十十も AT&T 本命だから , かなりシェア 前回まではソースリストの山だったので , を取りそうに見えるが , いすれもオプジェ る。 今回は「ちょっと息抜き」という意味もこめ クトへの指向の仕方が中途半端である , と この規格案の詳細を見ると K & R に比べて て , C 言語と UNIX についてのよもやま話を いう下馬評ばかりが聞かれ , まだまだ研究 , さほど大きく変わってはいない。自然言語 しようと思う。 が文法から作られたのではなく , 言語があ 趣味という分野を越えるものではないよう って , 後で文法が研究されたというように である。 さらに UI や OSF の動きも見逃せない。と C 言語も , ます C 言語があって , その後に くに最近では「 OSF はアブナイ。 AIX も一部 ういう規格案が作られたのだから , 当然と しかできていない」などという噂も贏かれて いえば当然の話だ。 最近よく耳にする言葉に「 ANSI 」というの いる。そうなると IBM という事実上の標準 ということは , 現状では ANSI 規格案とい がある。 ANSI は「 American National も危なくなる。現状はこと UNIX に関しては うのは不完全なものなのである。 Standard lnstitute 」の略で , アメリカでの IBM は標準でもなんでもない。歴史からい 現在の事実上の C 言語の標準は , パソコン 標準化委員会のことである。アメリカの標 っても UNIX は IBM とはまったく文化の違 の世界では MS ー C Compiler である。その証 UNIX と新しい C 言語。 C 言語の標準は ANSI 規格案か 106 CMAGAZINE 19 4

三田典玄の 実践 C プログラマ 養成講座 第②回 C 言語と UNIX C>CZ IBM しかし「わかりやすさ」とはいったいなん とによって私の財産を減らしていくわけだ。 事をしている。そしてわかりやすくするこ にくさ = 専門」という財産を切っては売る仕 カネを生む魔力が失せる。私は私の「わかり かりやすくなると , カネにならなくなる。 い商売につながる。わかりにくいものがわ 「難しさ」は売れる。そして独占できるい UNIX の文化 (?) だろう ? 108 CMAGAZINE 19 4 ければ本来いけないが , やっていない。だ ネルのソースリスト中には「これはこうしな ちこちに見ることができる。たとえばカー このような「人間的な」部分を UN Ⅸではあ 根性を現していて泣かせるものがある。 ラリ作成者の大会社のサラリーマン研究者 「危ないものには近づかない」というライプ ate 」と最後の「 e 」まで綴らなかったところが まった。ちゃんと 7 文字以内になるのに「 cre 「 creat ( ) 」なんて舌足らすの表現になってし ら , ファイルをつくる標準関数の名前が 数名を 7 文字までしか認識しなかった。だか ーコロロ 昔 , UNIX の C旨蚯はなんと変数名や関 れかやっておくれ / 」なんていうコメントが あったりする。 また , アプリケーションの中のコメント では「これは俺が悪いんしゃない / XXX 社 の UNIX の XXXX コールがおかしいんだ / 絶対におれのせいしゃない / 信してくれ / 」 なんてコメントを見ることもある。 たとえば最近話題の GNU プロジェクトで は GNU の etc ディレクトリの下に「 Cookies 」 なんていうファイルがあった。覗いてみた ら , 本当にクッキーの作り方が書いてある。 「バターが何グラム , 小麦粉が・・・・・・」という 調子である。知り合いの女性にこりファイ ルを見てもらったら , 「かなりあまーい奴が できるみたいだけど , かなり凝ってる本物」 だそうである。 こんなのはまだいいほうで , 同しディレ クトリ中に「 sex. man 」 ( 名前からしてヒワイ ですな ) なんていうファイルがあるので覗い てみると , 「そういう」コマンドの使い方が 出ている。ちゃんと UNIX のマニュアルのフ ォーマットで書かれている。「一 b 」でバック オプション , 「一 x 」でアプノーマルオプショ ン , 「一 0 」でアウトドアモード , という調子 である ( 女性の読者の方がいたらすみませ ん ) 。こちらは前記の女性に見せてコメント を求めた , なんてことはもちろんない。 こういうところまでくると , とても私の ような純真でナイープな感性ではとうてい 計りきれないものを感しる ( どこが / ) が , とにかくこういったファイルの探索も ( わざ わざ探すなっ / ) UNIX の楽しみのひとつで あることは確かである。 こういった文化カ℃言語の根底にあるのだ ということを知っていると重宝する , とい うことはないが , 少しは仕事がおもしろく なるかもしれない。 UNIX 文化というのはもちろんこれがすべ てではない。青い巨人の弾圧を恐れてか表 だっては誰もいわないが , UNIX はもともと 非 IBM のコンピュータ世界を明確に目指し て作られたコンピュータ世界であることは まちがいない。 分散データベースもパーソナルコンピュ ーティングも , もともとアメリカ西海岸の 1960 年代のカウンターカルチャーが作り出 したものばかりだ。 「中央集権ではなく非集中」であり , 個人 のパワーをどう広げていくかということを 明確に考える , という特長はまさにカウン ターカルチャーの思想の一部を実現してい るものだといってもまちがいはないだろう。 言葉でいうことはいくらでもできるが , こういった文化についての理解は , 明らか に UNIX というオペレーティングシステムへ の理解を深めることはまちがいない。この 「カルチャー」に出会わなければ UNIX を理解 したとはいいにくいだろう。 一度サンフランシスコの湾の対岸にある バークレイ大学周辺に行ってみるとこの「感 し」がよくつかめる。私も行ってみて初めて わかった。あの街にはまだ 60 年代の熱気が ほとんどそのまま「保存」されている。 OSF が Mach を採用したが , まだカーネル さえも完全にできていないという話は ,

研究所へ来られたのですか ? Stroustrup 拒否て、きないほどのはい ) 条 件を提示されたんて、す。 こには優秀な人 たちがいたし , おもしろいことがて、きる自 由がありました。 ベル研での環境 最初にここに来られたときにはコンピ ュータ言語環境はどのようなものでしたか ? また , どんなツールがありましたか ? Stroustrup 最初に来たころは , いわゆる UNIX システム 7 が DEC の PDP ー 11 / 70 上て、動 いていました。あまり記憶がはっきりしま せんが , PDP ー 11 / 45 も奥の部屋て、リタイア していたように思います。しかし , 現在知 られている UNIX ツールの多くがすて、に存在 コンピューティング環境以上に人の問題 が重要て、した。 というのは , 多くの時間を 各自の部屋て、働く人たちて、さえ UNIX ルーム ( ほとんどの UNIX ターミナルを置いてある 部屋 ) て議論や勉強にかなりの時間を費やし たのて、すから。コンピューティング環境は コンヒ。ュータのなかにあるだけのものて、は ありません。コーヒーメーカは CPU と同じ くらい重要て、した。 どのような人たちと親交がありました ィープ・ポーン , スティーフ・ションソン , Stroustrup サンディー・フレーザ , ステ 成 , スティープ・ジョンソンはポータブル ンは標準 UNIX シェル (Bourne Shell) を作 へん重要な仕事を行い , スティープ・ボ、一 ソンは UNIX 上のネットワークて、初期のたい ( サンディー・フレーザとグレッグ・チェッ ほとんどが UNIX ラボて、働いていた人々て、す グレッグ・チェッソン。それくらいて、すね。 モリス , プライアン・カーニハン , それに もちろんデニス・リッチー , ポプ・ そうスティープ・ジョンソンとはよく話し C コンパイラを作り , ボ、プ・モリスは世界的 に高名なコンヒ。ュータセキュリティの専門 家て、あり , プライアン・カーニハンととも にたくさんの UNIX ツールに貢献 , デニス・ リッチーは UNIX と C の開発者 ) 。 C の周辺 当時このグループで使っていたコンピ ュータ言語は C でしたね。慣れるにしたがっ て C のどこがよい点と感じ , どんな点がいや だったり不足していると感じましたか ? Stroustrup 当時て、は珍しいことて、すが , 実はここに来る前に多少 C を知っていたのて、 す。 1970 年代の話て、 PC 時代の前て、す。 ケンプリッジて、の経験の後て、 , 驚いた とに基本的には C を使えばやりたいことが何 て、もて、きたのて、す。 UNIX はオープンシステ ムて、ありオペレーティングシステムに手を 延ばすことが可能て、 , あるかぎりのツール に手を出すことがて、きました。何かアイデ アがあればそれを表現することがて、きたの て、す。効率よく何かを実行するアイデアが あればそれも表現て、きました。 当時は何かをしようとしても言語による 制限が多すぎました。、、スヒ。ードならだいじ ようぶ。ただしスーパーオプティマイジン グコンパイラが必要て、 , それは来年まて、て、 きないし , 値段が高くて手の届かないマシ ンが必要て、す〃と多くの言語が語っていま した。しかも通常のデバッキングコンパイ ラと比べると , 最適化コンパイラにはいく つものバグと制限があり・・ したがって単純なコンパイラて、まあまあ のスルーブットが得られるということ , そ れが重要てした。 C の欠点 Stroustrup C に関して好きになれなかっ たのは , たくさんの領域にわたって C て、書く B. Stroustrup C 十十の生みの親 と , 正しく動くことよりまちがっていること のほうが多かったからてす。プログラムを 書くためのファシリティ (facility : 設備 , 便宜 ) が不足し , プログラムの解決方法を考 えるためのファシリテイも備わっていませ ん。 Simula ( シミュレーションのためのすぐ れたファシリティをもっている汎用コンピ ュータ言語 ) を知っていたのて、 , その言語を 使って表現するだけて、なく , 達成したい解 決方法を考えるのにもクラスの概念が強力 て、あることはわかっていました。私の本の 冒頭には , 考えられることへの影響 , そし て考えられることへの制限を言語が与える ということについてのドイツの哲学者ヴォ ルフの言葉を引用しています。 医学の分野で , 病名を発見するまでは 治療法がわからない , という状況がありま すが , それに似ていますね・・・ そのようて、す。ソフトウェア Stroustrup というメディアをしつかり把握するのはた いへん困難て、す。具体的て、はないし , 機械 設計て、は起こりようもないばかげた失敗を することさえあります。したがって , もっ 言語は想像の対 と言語の助けがほしいし , 象にまて、影響を与えたりします。 C や BCPL に不足していたのはこのような ' とて、す。ケンプリッジて、シミュレーショ ンをしていたとき , Simula て、ものすごくい いものが書けました。 とてもおもしろかっ たのて、すが , やはり手に負えませんて、した。 IBM メインフレームを停止状態にしてしま ったのて、す。博士号なして、ケンプリッジを 去るか , ほかの方法て、シミュレーションを 行うかどちらかて、した。そこて、 BCPL て、プロ グラムを書き直しました。 BCPL は C の祖先 て、あり , (BCPL から C を見ると ) まるて℃が 高級言語に見えました。 BCPL て、記述するの はたいへんて、したが , 一度書き終えると目 も眩むほど高速て , ほかにだれもコンビュ ータを使っていなければ・・ C 十十の生みの親 11

0 ( 三田典玄の 実践 C プログラマ 養成講座 五ロ ニ = ロ あがった本を訳者 , 監修者全員 ( 10 人ほどい た ) が初めて見た。そこで , その本を手にし た全員が思わすこう漏らした。 「わ , わからん。さつばりわからん。難 0 0 しい。」 私もそう思った。が , この本は短い間に かなり売れた。監修者でもわからないくら い難しい本だから , 売れたのである。類書 がアメリカにも日本にも数少ない , という ファクターもあった。が , ほんとうは「わか りにくい」から売れたのではないだろうか。 う「コンピューティング」を指向しているの でもするという程度におっきあいするのが 誰が見たって , こんな難しい本 , 簡単に はわかりつこないのだが , どう考ても本来 よいのではないだろうか。 で , 同しノイマン型コンピュータといって もその基盤が違う。このまま UNIX の攻勢が しかし , 私のようにこんな文章を書いた の需要以上に売れているのである。 り , C 言語の本でいくばくかの稼ぎを得てい そしてもうひとつつけ足しておくと , 「 C 続くと「 IBM = lwate Business Machines ( 岩手事務機 ) 」などという皮肉として関係者 る人間がこのようなことをいってはほんと マガジン」 2 月号や前記の「 UNIX デバイスド うはいけない。もっと難しい「基準」「標準」 の間で一時聶かれていたジョークが現実に ライバ」で説明している構造のデバイスドラ なりかねない。ベルリンの壁がなくなった をたくさん作ってコンピュータ世界をわか イバはもう時代遅れであって , 現在の実業 と思ったら , もう 1 か月後には渋谷の東急ハ りにくくし , 「専門家」がたくさんできない に役に立つ面はさほど多くない。 ンズの文房具売り場でそのカケラが 1800 円 ようにしなければ「商売の独占」はあり得な 私の会社でも数々のデバイスドライバを ナリで売られているし , 今度の選挙では自 い。つまり甘い汁が吸えなくなる。わかり 書く仕事をしているが , 最近はこれらの本 民党危うしなどと叫ばれている ( この文章は やすい本や文章はこの業界の敵である。だ や文章で説明されているかたちのドライバ 選挙前に書いている ) 昨今 , IBM などという から , C マガジンなどが売れるようにするた を書くことは少ない。なくはないが , もう 世界企業のひとつやふたっ , いつでも , ど めには , C マガジンには難しいことが書かれ 時代遅れ , といった感しがする。 うにでもなってしまうというところに現代 ていなくてはならない。 最近の UNIX のデバイスドライバはまった の面白さを見るのは私だけだろうか。 IBM 「 UNIX のカーネルも読んだことないの ? く違う構造をしているものがほとんどであ を生んだアメリカ自身も , なんだかそのあ キミしやダメだね」というような他人を見下 る。 せりばかりが目につく今日このごろである。 したような態度が取れれば , あなたもこの 簡単にいうと「本になってしまったものは 業界で食っていける ( ほんとかいな ) はすで もう最先端ではない」のである。 IJN Ⅸのカ ーネルそのものも UNIX とは名ばかりで , 中 ある。 身は全然違う構造をしているものも数多く 先日 , 「 Writing A UNIX Device Dr ⅳ ers 」という本の翻訳をアスキーから出し ある。マルチプロセッサのサポートやら , た。正確にいうと私が訳したのではなく「訳 : リアルタイムスケジューリングの追加やら , 中野浩一 / 大西照代監修 : JUICE 」という 未知のファイルシステムの追加ができるよ ことで UN Ⅸネットワークを主体とする私た うになっているものやら , ネットワークで ち JUICE という団体が監修をしたのであ の密結合対応やら・・・・・というわけだ。 る。この出版記念のパーティの席で , でき 「わ力。らん / 」 と , いうわけで「標準がない」「基準がない」 というふにやふにやしたところが買われ , そして広まった「 C 言語」に「基準」を作るとい うハナシは , なんとも現代的なおもしろい 現象ではないだろうか , と落語のまくらに 実践 c プログラマ養成講座 107

( Ver. 1.37 て、は直っているかも ) , アマチュ アて、ある私が使用するには十分な信頼性を もっています ( それて、はプロが使うには耐え られないのて、しようか ? これは GNU ソフ トウェアはすべて無保証て、あるのて、あえて こういいました。 gcc を使用していると , 多くの場合メモリ 不足に悩まされます。 GNU ソフトウェアは 仮想記憶機能をもったマシンを前提として いますから , その機能をもちあわせていな い X68000 て、は物理メモリを増やしてやるし か対処方法はありません。コンパイラ自体 のサイズも MS ー DOS のカべ 640K にせまる 500 K バイトて、す。 本格的に gcc を使用する場合には 4M 以上 のメモリを用意したほうがよいて、しようが , これだけのためにメモリを増設するのはや つばりマニアだけて、しよう。 G 移植挫折編 同じく GNU がテストリリースしているコ ンパイラに g 十十があります。これは GNU CC に C 十十のフロントエンドを結合して作 成された C 十十ネイテプコードコンパイラて、 す。 本誌て、も紹介されていますのて、 , ご存じ の方も多いて、しよう。これを X68000 に移植 して動かそうと思ったのは , 4M 増設 RAM ポードを購入して , gcc て、のコンパイルに間 題がなくなったころてした。 現実的な問題として , X68000 程度のマシ ンパワーて GNU ソフトを移植するには相当 な時間的困難がともないます (BISON 注 4 や FLEX 注 5) くらいならそれほど難しくあり ませんが・・・・・・ ) 。最初に移植を試みたのは Ver. 1.34.0 てした。先ほども述べました が , g 十十はコンノヾイラのコードジェ不レー タ部分を gcc に依存しています。 C 十十の文 法にそって構文木を作成し , 内部コードて、 ある RTL コードに展開するまてが g 十十フロ ントエンドの仕事て、 , そのあとのマシン依 存部分は gcc を流用してあります。したがっ て , ま igcc のソースを用意しなければなり ません。 ソース自体はパソコン通信のフロッヒ。ー べースて、配布がありましたのて、 , それて入 手しておりましたにの場をお借りして , 配 布してくださった方々に感謝の意を表しま す ) 。 GNU ソフトは UNIX マシンて、は通常磁気 テープて、配布されますが , すて、に配布され たときにはフロッビーに転送されておりま した。当然 , IM しか容量はありませんの て、 , 一部の巨大なソースや diff ( 注 6 ) は UNIX 上て、 tar&compress ( 注 7 ) され , ish ( 注 8 ) て、 分割されて格納されていました。 ish, tar, compress はすて、に X68000 にも移植さ れており , 展開ツールには問題ありません て、したが , 物理的な EWS との性能差は非常 に大きいのて、一朝一タにはて、きないのて、す。 余談になりますが , SONY の NEWS て、 GNU ソースを compress したことがありま す。が , そのスピードにはちょっと驚かさ れました。やはり , EWS とパソコンとて、は 歴然たる差があることを痛感しました。 さて , RAM ディスクを 4M バイト確保 し , フロッヒ。ーに分割されている ish 形式の ファイルをひとつに結合して , is れ形式から commpress されたデータ ( バイナリの UNIX てはサフィックスが . Z になる ) に展開しま す。 作業は RAM ディスクに is れファイルを置 き , HDD に展開します。ところがこの段階 て、さっそくつまづきました。 Human68k< は許されないファイルネームの g 十十 . taz に なっていました。しかたなく , ファイルオ ープンルーチンをデバッガて、探し出し , パ ッチをあてて展開して , なんとか解決しま した。このファイルネーム制限は後々まて 呪いのようにつきまとうのてすが , 結局フ ァイルシステムの根本的な違いなのていた しかたないところて、しよう。 ソースを compress て、展開し , tar て、完全 なソースファイルに戻してやります。 X68000 の tar は Human68k て、許されないファイルを リネームして展開してくれるのて一見問題 なくファイルが生成されました。 ところが , 実際コンパイルしてみるとゾロゾロエラー が出てきます。大半はヾ Conference Room 133 されないキャラクタのひとつ。 ( 注 9 ) Human68k< はファイルネームに許 てきる。 分割すれば何枚かの FDD に転送することが compress し , これ <ASCII ファイルにして するツール。 UN Ⅸての巨大なファイルを 訂正機能を付加して ASCII ファイルに変換 トコンバータ。バイナリファイルにエラー ( 注 8 ) パソコン通信の世界ては有名なビッ UNIX のファイル圧縮ツール。 てて使う仕様になっている。 compress は イバ。 X68 や 98 の tar は FDD をテープにみた ( 注 7 ) tar は本来は UNIX てのテープアーカ ルて生成してそれを供給している。 は , 元のソースからの差分を diff というツー ( 注 6 ) gcc などはバージョンアップの際に タを作ったりして遊んてる。 ( 語尾を「山瀬まみ」風にしてしまう ) フィル UNIX の lex に相当する。私はこれて「まみ語」 ( 注 5 ) GNU の高速字旬解析ジェネレータ。 はこれてコンパイルして生成する。 の yacc に相当する。 gcc, g 十十のノヾーサー ( 注 4 ) GNU のコンパイラコンパイラ 0UNIX きしてしまい , 存在していなければならな いるものは , tar が既存のファイルに重ね書 この結果 , 先頭 8 文字が一致してしまって にありました。 しないという , MS-DOS 仕様の Human68k 原因はファイルネームの先頭 8 文字しか識別 除いても不可解なエラーがまだ出てきます。 ところが , この手のエラーをすべて取り ませんて、した。 ないエラーて、 , これは大きな問題て、はあり ームされている ( 注 9 ) のて、ヘッダが見つから

0 0 3 さ 100 フィートの垣根に 10 フィートご は , 笑いを誘うのだ。まちがいを犯すこと とに支柱を立てるとしたら , 支柱は は , いかにも人間的だからだ。本書を読む 何本必要カ これが本書の序章 ( 第 0 章 ) 人は , プログラミングが、、人間的なあまり の練習問題のひとつである。大人でも , そ に人間的な〃行為であることを , 改めて再 してふつうの大人よりも厳密な頭脳を要求 確認するだろう。 されるプログラマでも , つい 10 本と答えて そして , ベル研には , プログラミングを しまうことがある。人間はつねに , まちが 人間的行為として遇する伝統があるように いや錯覚を犯す。 思える。今でこそ本格的な商業的ソフトウ システムの仕様はつねに単純明快だが , ェアへと成り下がってしまっている UNIX 人間ははとんど , 単純さからは遠い。 も , ある種のジョークから生まれ , 初めは int は MS-DOS 機などの上の C では 16 ピッ 大学などにタダで配付され , 普及していっ ト , もっと高級なマシンだと 32 ビットだ。 たものである。 そしてストリームから文字を読む getc ( ) な デニス・リッチーもいっている「 UNIX は どは , たしかに一度に 1 バイトしか読まない ベル研の自由でイキイキとした , オープン のに , なせ返り値は int と定義されているの な雰囲気のなかだからこそっくれたのだ」 だろう。 ( ACM 賞受賞記念講演 ) 。たとえば AppIe 社 MS-DOS のテキストファイルの改行文字 は些細なことで Microsoft 社を著作権訴訟し は 0x0d 0x0a の 2 バイトだ。でもなぜ C の関 ているが , 重要な機構のはとんどが UNIX の 数を使ってバッフア内に行を読み込むと , 物真似である ( 2.0 以降の ) MS ー DOS に関し OxOa しか読み込まないのだろう。 0x0d はど はない。そうではなくて , すべてのプログ て , AT&T などが訴訟したという話はない こに消えたのだろう。 ラミング言語 , いや , プログラミングとい つまり AT&T の UNIX ではなく , ベル研 ふたつの非負の int 変数の和のオーバーフ う行為そのものに , つねに、、落とし穴〃が の UNIX, そして世界の大学などへと広まっ ローは , なせ , if(a 十 b<O) では正しく検出 ていった「 UNIX コミュニティのフリーな雰 つきまとっているのである。 できないのだろう。 囲気」には , 今後のパーソナルコンピューテ 本編は 7 章からなり , 約 50 種の個別テーマ y Ci + + ] = x Ci] ; と書いたとき , x [i] を扱っている。以下 , カッコの中はその章 イングが範とすべきものが , あるのではな の i の値が , この式の左辺でインクリメント のテーマのひとつである : ①語句的な落と いだろうか。これは , 一介の MS-DOS ュー された後の i ではなくて , される前の i である し穴 ( = と = = の書きまちがい ) , ②構文的 サの、、憧れクにすぎないのだろうか。 こともある。なぜだろう。 な落とし穴 (else のかかり方に関する錯 本書の原書は , 私が勝手に心に描く「ベル メモリの 0 番地から始まっているサプルー 覚 ) , ③意味的な落とし穴 ( ポインタと配列 研の精神的風土」への憧れを裏切らない , く チンをコールしたいとき , ( * O) ( ) ; と書い の違い ) , ④リンク ( 名前の衝突 ) , ⑤ライプ だけた , しなやかな , 軽い工ッセイふうの て「関数へのポインタだ」と主張しても , C コ ラリ (fseek( ) はいつ必要か ) , ⑥プリプロセ 文体で終始している。 ンパイラは OK しない。どうしてだろう。 ッサ (#define と typedef の違い ) , ⑦移植性 そのほんの一例 : 本書の原書 TC Traps and Pitfalls 』 ( わり算の切り捨て方の違い ) 。 lt is tempting , butsurprizingly diffi は , AT & T ベル研のソフトウェア技術セン そして付録で , printf( ) 族の関数の書式 cult, tO define mac ー ros that act like 指定のまちがいやすい点を , 詳しく指摘・ ターに勤務する著者が , 前任地であるコロ statements. 解説している (va ンピア大学時代に , 、、 PL/I Traps and Pit ・・・の使い方にも言及 ) 。 ( 中村訳 ) 文のように動作するマクロを定 本書は , 勉強になるばかりでなく , 読む falls" と題する講演をした経験を踏まえて 義することは , 魅惑的だが驚くほど難しい。 まとめた「 C プログラミングの罠と陥穽」集で こと自体が楽しい。なぜだろう。原著者は このくだりは , 誰もがやってみたくなる ある。つまり , 本書の訳者はやや誤解して 日本版に寄せた序文で「学ぶことと笑うこと けれども , 実際にやってみると意外と難し いるようだが , とくに C 言語だからプログラ は万国共通」と書いている。さよう , 人が , い , というニュアンスを述べているんだけ ミングエラーの原因となる難関が多いので そして自分が , プログラミングで犯す誤り どなあ・・ 岩谷宏 0 今月の書籍・ 長 ℃カクラミングのし穴』 C and PiffaIIs C プロクラミングの ・とし穴 [ 艸円い A. コーニグー物 中村等 , BAnd 「 ew Koenig 著 ■中村明訳 ・株トッパン , 158 頁 , 2300 円 22 CMAGAZINE 19 4

低水準ファイル 入出力関数 さて , ます「低水準ファイル操作」から説 一般には , ファイルの入出力関数は低位 水準関数と高位水準関数のふたつに分けて いる。これはハードウェア ( あるいはシステ ム ) に近いか , 遠いかによって「低い」「高い」 と区別されている。 ところて、 , よく低水準ファイル入出力関 数を使ったプログラムは , 互換性がなくな ってしまう , ということがいわれる。互換 性というのは , 同じ処理系て、も ノヾーション の違いも含めて , 異なる処理系との違いを 指している。つまり , 作成されたソースフ ァイルが , 修正する必要なく動作すること を互換性があるという。だが , 実際には話 どおりにうまくいくことは少ない 同じ MS ー DOS 上の処理系ならそうこだわる ことはないとも思える。むしろ互換性とい [Tbl.1] 低水準ファイル入出力関数のランタイムライプラリの比較 MS-C access dOS getfileattr chmod dOS setfileattr chsize close dOS close creat dOS creat dOS creatnew mktemp dup dup2 eof filelength fsta t dOS getfime locking lseek open dOS open read dos read 「 ename re m ove dOS setftime setmode sopen stat tell umask unlink write dOS write TurboC access chmod chmod chsize close close creat creat creatnew creattemp dup dup2 eof filelength fstat getftime lock lseek open open read read rename remove setftime setmode sopen stat tell umask unlink unlock write write 機能の説明 ファイル属性の取得 ファイル属性の取得 ファイル属性の変更 ファイル属性の変更 ファイルサイズの変更 ファイルのクローズ ファイルのクローズ ファイルの新規作成 ファイルの新規作成 ファイルの新規作成 一時ファイルの作成 ファイル八ンドルのコピー 指定八ンドルへファイル八ンドルのコピー ファイルの終端を検出 ファイルの長さを取得 オープンファイル情報の取得 ファイルの作成日時を取得 ファイルにロックを設定 ファイルポインタの現在の位置を移動 ファイルをオープン ファイルをオープン ファイルからの読み込み ファイルからの読み込み ファイル名の変更 ファイルの削除 ファイルの日時を設定 テキスト / バイナリモードの設定 ファイルを共有モードでオープン オープンファイル情報の取得 ファイルポインタの現在位置を取得 ファイル属性をマスク ファイルの削除 ファイルのロックを解除 ファイルへの書き込み ファイルへの書き込み ラ気プ 9 リ った場合 , どちらかというと UNIX 互換を意 識していると見たほうが正しいのかもしれ ない MS ー DOS は Ver. 2.11 て、 UNIX のファイル システムを取り入れて以来 , ノヾーションカー 上がるたびに UNIX の機能が少しずっ取り入 れられている。 MS-C にしてし TurboC にし ても , ランタイムライプラリのマニュアル には UNIX と互換かどうかがわかるように記 載されている。 通常 , 互換性を問うようなランタイムラ イプラリは , 低水準ファイル入出力関数よ りも , 高水準ファイル入出力関数にほとん ど集中している。 ANSI C て、も , 低位水準の 関数て、はなく , 高位水準の関数に対して規 定している。高位水準の関数は UNIX の機能 を取り入れたものが多く , 逆に低水準ファ イル入出力関数は , どちらかといえば MS- DOS のシステム関数を C 言語からて、もなるべ く簡単に使えるようにしたものがほとんど て、ある ( もちろんすべててはないが ) 。そし て , 低水準ファイル入出力関数は MS ー DOS のシステムコールに依存しており , したが ってそれは「低い」のて、ある。このように互 換性の問題を通して低水準入出力関数と高 水準入出力関数の違いを見てきたが , ただ , 低水準ファイル入出力関数といっても , MS -C と TurboC て、は , ランタイムライプラリが 異なっていることがある。その違いの比較 を表にした ( Tbl. 1 参照 ) 。 低水準ファイル入出力関数が MS ー DOS の システムコールに依存しているところをフ ァイルのオープンを行う open ( ) 関数て、説明 しよう。 open ( ) 関数は , 成功すると int 型の ファイルハンドルを返すことになっている。 ファイルハンドルは , MS-DOS のなかてほ かのファイルと区別するためにつけられた ファイル識別コードて、ある。同時に , この ファイルハンドルは , MS-DOS のファンク ションコールによって扱われているラアイ C プログラマのためのランタイムライプラリ入門 えれば , 低水準ファイル入出力関数い ルハンドルと同じものて、もある。単純に考 83 、フ

もう分解することができないロジカルな単 位であるにもかかわらす , たとえばバイト 単位だと 1 バイトすつに分けられ , わけのわ からないものにされてしまう。 また , 意味をもつかたまりとしての論理 単位を切り離してしまうという問題もある。 ェスケープシーケンスのようなコード系を 考えた場合 , 本来シフトインというロッキ ングシフトがあり , そのあと「日本語」とい うマルチバイトコードのモードになってい て , シフトアウトがくるまでモードがコン テキストとして保存されているわけなのに これを , ・・ ( シフトイン ) 日、、十〃本語 ( シフト アウト ) ・・ というように適当なところで切ってしまっ たとすると , 意味をもつかたまりから切り 離されてしまったそれぞれのかたわれは , いったいどのような意味をもつのであろう こういう日本語処理のさまざまな問題 か ? が発生してきた。 ところが , これらの諸問題を従来の 1 バイ ト = 1 文字の範囲で無理して扱おうと思って も , 結局は , 小手先だけのたんなる回避し かなされす , さらにそこからさまざまな問 題が派生してしまっている。そこで , この ようなマルチバイト文字が入っても , 1 バイ トが 1 文字であった古きよき時代の処理と同 様の処理が可能な言語要素を , なんとか加 えられないだろうかというのが , 日本語処 理のそもそもの発端であり , 日本側からの 提案であった。 今までは , 1 バイト単位での操作しかでき ないような言語仕様の世界で , 今述べてき たようなさまざまな問題点をアプリケーシ ョンプログラムを組み , なんとか回避・処 理していたわけだが , それにしても , マル チバイトコードが文字列リテラルのなかで 衝突したりすることを避けるのは非常に困 マルチバイト 週里機能導入の目的 特集 AN 0 の現状 TbI.1 C における多バイト処理機能導入の目的 ( 日本の立場から ) ①従来の文法の範囲で , ASCII, 日本語混じりのテキストをノヾイト単位に操作して きたものを , コードの衝突などが起こらないように文法として整合のとれたものに ②さらに , 「日本語文字を 1 文字として扱う」ために , ASCII, 日本語も含めて , 同 ー長の 1 文字として扱える機能を導入し , 操作を容易にしたい ③日本語のみならす , 「多バイト言語圏」 ( 中国 , 韓国など ) に通用する一般性のある 文法として , 国際標準として認知させたい 難であろう。少なくとも今示したような例 は , たとえば 16 進表現で記述することによ ってなんとか避けているわけだが , しかし , 小手先の回避ではなく 旨仕様としてき 「コロロ ちんと保証できるようなスペックを作って ほしいと願わざるをえない。 そのためには , マルチバイト文字はきち んと 1 文字として扱える , つまり , 1 文字が いくつのバイトから構成されているかをア プリケーションが意識して処理するのでは なく , ちゃんと 1 文字は 1 単位で , それ以上 分解できないような単位として扱えるよう なコンセプトを導入しなければならないの だ。 要するに , 普通の ASCII 文字と同しように 日本語 ( あるいはもっと広くいえは中国語や 韓国語など ) を扱えるメカニズムを導入した い , 日本語を含むテキストを「 ASCII のみの テキストの操作」のように扱える言語仕様が はしい , ということである。そのために 日本語の範囲でます概念を築き上げ , その 後に中国語や韓国語なども扱える汎用的な 構造を作ったうえで , 国際標準化していき たいというのが日本側の主旨である。これ を TbI. 1 にまとめる。 マレチバイト機能の標準化の経緯 こでは ,ANSI C の国際化機能 ( インタ ーナショナライゼーション ) の現状と , 国内 にある SC22 の C ワーキンググループ ( SC22 / C (G) のドラフトについてみていく。 マルチバイトの問題をたぐってみると , 日本国内で日本語処理問題を検討する組織 が発足したのは 1984 年 10 月だった。当時 , AT& T ュニックスパシフィック (AT&T (P) が日本語を含んだ UNIX を作るためにそ の諮問を東大の石田晴久氏に依頼 , 氏が委 日本での日本言課理の発端と SC22 / C ワーキンググトプの誕生 員長になり , メーカーなどが参加して日本 語 UNIX システム諮問委員会 (Japanese UNIX System Advisory Committee) を 発足させた。以後 , この諮問委員会で作成 された案が日本語処理概念の原型になって いる。 そこで討議された答申案は , 日本語 UNIX システム諮問委員会の報告書という形で AT&T UP から 1985 年 3 月末に発表されてい る (Proposal of Japanese Capability in UNIX System V)O 同時に , この答申案を べースに国際的な場で提案する旨が付帯条 件としてつけられて , AT & T UP に諮問さ れた。また , システムプロジェクトが発足 特集 ANSI C の現状 51

ンマイ ラブリ List 2 調べるのだろうか ? eof. c(List3) を見てい ただきたい このプログラムは , ディスプレイから入 力された文字が EO かどうかを調べ , その ままディスプレイに返すものて、 , EOF な ら , このプログラムが終了する。また , 次 のようにも操作することがて、きる。 A 〉 EOF く FILENAME. DOC ところが実際に EO として認識されるの は , 先ほども述べたように MS-DOS カ℃ P/ M からひきずっている規則て、 CTRL 十 Z な のて、ある。 CTRL 十 Z は , たしかにファイ ル終了を示しているが , 現在てはこのコー ドを使用しない方向にある。とくにマイク ロソフト社ては , 毛嫌いしている。そのた め , C 言語てはファイルの終了という意味に は理解しないようになっている。たとえば , read ( ) て、は , ファイルの終端にきたら 0 を返 すようになっている。そして , EOF はヘッ ダファイル stdio. h に ( ー 1 ) として登録されて おり , ファイル終端の検出を目的としてい るとすれば , List4- ①はまちがいといえる。 この EOF は , ファイルの終端というより もエラーフラグとしての意味をもっている。 だから , 工ラーとしての EOF の意味を正確 にこの文に反映させたいのなら List4 ー②のよ うにせざるをえないだろう。 while 文のかわ りに if 文を使用することもてきる。 これて , ファイルの終端を調べているの か , 工ラーを検出しているのかがはっきり とわかる C のプログラムになった。 eof ( ) 関 数と EOF 定数の使い方は , ともにファイル 終端の検出にある。そのため , その使用方 法において , 徴妙に使い分ける必要がある だろう。この EOF 定数は , UINX< よく使 ほとんどのサンプルプログ 用され , また , ラムが UNIX からのものなのて , MS-DOS ューザの誤解のもとになっている。そのた め , eof ( ) 関数と刊 OF 定数を使っているプロ グラムては , 移植性について検討を加える 必要があるかもしれない 112 : 113 : int main(int argc, char *argv ロ ) 114 : { 115 : char *p : 116 : if( argc 118 : 119 : 120 : 121 : 122 : 123 : 124 : 125 : 126 : 127 : i f ( argc 128 : if( copy( argv[l], argv[2] ) 129 : 130 : return ( 0 ) : 131 : 132 : 133 : puts ( " ファイルの指定が間違っています . " ) : 134 : 135 : puts("USAGE 1 : cpy filel fiIe2"); puts("USAGE 2 : cpy filel"); 136 : 137 : return ( 138 : 139 : ERROR: 140 : 141 : 142 : 143 : 144 : 145 : } 146 : = strrchr(argv[l], P p 十十 : if ( copy( argv[l], p ) return ( 0 ) : ー 1 ) goto ERROR : ー 1 ) goto ERROR; puts ( " ファイルのコビーに失敗しました。原因としてはファイルオープン " ) : puts ( " に失敗したか , 書込み損じたかのどちらかのようです。 " ) : return ( eof. C List 1 : #include く stdio. h> 2 : 3 : void main( void ) 5 : i nt C : 6 : while ( (c = getchar() ) ! = EOF ) 7 : putchar( c ) : 8 : List い st4- ① while( read( fd. buf, size ) ! = EOF ) い st4- ② while( eof(fd) ) read( fd, buf, size ) ! = C プログラマのためのランタイムライプラリ入門 89