2 移植性阻害の要因と対策 c 言語プログラムの移植性はさまざまな環境の 調和の上に成立しているといっても過言では ド・ソフトなど , C 言語を取り巻く 環境の相違にどのように対応すれば c 言語の移 植性を発揮できるのであろうか。 、すウェア環境 絶、アドレスの使用 / 特定の 理テパイスの参照 な、問題か たとえばシリアル I/O を行う場合に , ある 機種て、はインタフェイスチップとして 8251 A が使われていて , その内部レジスタが 30H ードウェア環境に関しては , ターゲッ 何がいったい移植性を低下させているの から 35H まて、の I / O アドレスに割り付けられ トマシンのシステムアーキテクチャに関連 て、しようか ? 具体的な問題点をあげてみ する問題に限定します。解説の都合上 , タ ているという事実に依存しているソフトウ ます。 Rabinowitz と Schaap は , その著書 ーゲット CPU のアーキテクチャに関連する ェアは , インタフェイスチップに異なる品 fPORTABLE C 』 [ 1 ] て、 , 突き詰めればす 種のものを使用していたり , 同じチップを 問題はソフトウェア環境て、まとめて考察し べての移植にまつわる問題点は次のふたっ 使っていても , 異なるアドレスに割り付け ます。 の原因に帰着するとしています。 ているマシン上て、は , 仮にそのほかの問題 ①環境への依存性 システムアーキテクチャへの依存 が一切なかったとしても動作しません。 ②処理系特有の方言の使用 これは実に明快て、しよう。ターゲットマ 同様の問題として , i80x86CPU のある機 環境には「コンパイル時の環境」と「実行時 シンのシステムアーキテクチャとは , たと 種て、はテキスト VRAM が A000 : 0000 からの の環境」のふたつの観点があり , また別な視 えばメモリマップ ( ある番地から別の番地ま 4K バイトて、あるのに対して , 別の機種て、は 点から考えれば「ハードウェア環境」と「ソフ て、のメモリは RAM なのか , ROM なのか , 同じ CPU を使用しているものの , テキスト トウェア環境」が存在します。これらの概念 何のために使われているのかなどの情報 ) や VRAM は E000 : 0000 からの 4K バイトて、ある は本来直交しているはずなのて、すが , 実際 I/O マップ ( I / O 機器に関する同様の情報 ) , というような違いがあげられます。また , に問題となるのは「コンパイル時のソフトウ あるいは ROM のルーチン , すなわち BIOS テキスト VRAM など存在しないという機種 ェア環境」と「実行時のハードウェア環境」お や LIO などて、代表されるマシン固有のファー もあったりします。そのような場合に , テ よび「実行時のソフトウェア環境」の 3 種類て、 ムウェア機能が一体となって提供している キスト VRAM の内容を絶対アドレスを指定 しよう。ただし , いくつかの問題点は複数 機能仕様の総称と考えることがて、きます。 してアクセスするようなコーディングをし のカテゴリにまたがって存在し , その境界 た場合 , 機種依存となるのは明白て、す。 もし , あるソフトウェアがそれらの機能に は曖昧な部分もあります。また処理系特有 直接依存してる場合 , そのマシンと同一の の方言というのも , ソフトウェア環境に含 ファームウェアの利用 システムアーキテクチャをもったマシンて、 まれるとも解釈て、きます。そこて、 , ここて、 ないと移植て、きません。もう少し具体的に ROM に固定された機種固有のファームウ は単にハードウェア環境とソフトウェア環 ェアというものは , ソフトウェア制作者の 考えてみましよう。 境に分類して話を進めます。 44 C MAGAZINE 1991 5 の 1 題

る評価もさまざまて、す。移植性という観点 からみれば , つねに最低の評価を受けてい るのは機械語やアセンプリ言語などの , 別 名「低水準言語」て、す。これらは明瞭に CPU のアーキテクチャに依存しています。 一方 , 高水準言語 ( 高級言語とも呼ばれま す ) は通常移植性が高いといわれています。 それは高水準言語て、は , 機能を抽象化して プログラマから CPU のアーキテクチャをは じめとする物理的な環境を包み隠すように しているからて、す。先の移植の定義からも 明らかなように , ソフトウェアの移植性を 阻害する根本的な原因は , 環境への依存部 分が存在することにあります。裸の環境に 触れることがて、きない言語て、あれば , 当然 ながら環境への依存度が低下し , 反比例的 に移植性は良好になるわけて、す。 以上の説明から , C は本当に移植性のよい プログラミング言語なのだろうか ? う疑問をもった人もいるのて、はないて、しよ うか。「 C はアセンプリ言語のフレキシビリ ティとアセンプリ言語のパワーを合わせも った言語て、ある」というショークが示すよう に , 高水準言語のなかにあって C はアセンプ リ言語に近い面を有しています。あるいは , C は高水準言語て、はない。あれは中水準言語 て、あるという意見もあります 0K&R にも「 C は比較的低水準の言語て、ある」と記されてい ます。先の比較論て、いえば , 物理的な環境 を包み隠さずに , プログラマに比較的あり のままに裸の環境を見せているのが C なのて、 す。そのような言語て , はたして移植性の よいソフトウェアを書くことが可能なのて、 しようか。 組み込みの 8 ビットプロセッサ用のプログ ラムとスーパーコンヒ。ュータ用のプログラ ムとの間て、移植性のあるプログラムが書け るならば , これはもう願ってもないことて、 す。しかし両者の間て、 , 大規模なソフトウ ェアがほんの一部のソースの修正だけて、移 植て、きるなどとは , なんとなくありそうも ないような話にも聞こえてきます。 現に , 同じコンヒ。ュータ ( たとえはア C ー 9801 ) 42 C MAGAZINE 1991 5 の上て、 , 同一のオペレーティングシステム ( たとえば MS ー DOS ) を使っている場合て、す ら , たかが使っているコンノヾイラが違うと いうだけて、 , ソースプログラムがコンパイ ルて、きないとか , コンパイルはて、きたもの の期待したとおりに動作しないという話は 随所に転がっています。 また本誌をはじめとする雑誌類に , よく 「〇〇〇プログラムの△△△への移植」など という記事が載っているのを目にします。 もちろんそれらのプログラムは C て、書かれて います。移植先の△△△は別なコンヒ。ュー タシステムて、あったり , 別な OS て、あった り , 別なコンパイラて、あったり , ときとし て同じコンパイラの異なるバージョンて、あ ったりします。そもそも C が完璧な移植性を 備えたプログラミング言語て、あれば , この ようなテーマが記事になるはすはないて、し このような事態を目の当た ると , いずれが正しいのかわからず , よんとなく 狐につままれたような気分になる人もいる のて、はないかと思います。筆者の最初の主 張はこうて、す。 C は特別に移植性に優れたプログラミン グ言語ではない 詳細は後て、述べますが , C の言語仕様はか なりの部分が「処理系依存」て、す。裸の環境 に直接依存しているかどうかに関わらず , ソースプログラム上のまったく同一の記述 がコンパイラによって異なる解釈をされた り , ターゲットマシン上て、異なる動作をし , 異なる結果を得る場合があるのて、す。正式 に決定した ANSI C 規格て、すらそうなのて、す から , それ以前の de facto standard( 事実 上の標準 ) しか存在しなかった時代のコンパ イラ間には , 言語仕様の細部の相違がかな り存在すると考えねばなりません。 しかも , C て、はその高い自由度を反映し て , 環境に強く依存するコーディングを行 ことも容易て、す。当然ながらそれらのコ ーディングがなされてしまうと , 移植がき わめて困難なプログラムとなります。それ らの環境に依存したコーディングは , グラマがとくに意識していなくても , っとした不注意からなされてしまうことが あります。したがって , 次の主張はこうな ります。 ちょ プロ 注意深く気配りをしておけば , そのような 移植性を高めようと , あらかじめかなり こともできる C では移植性の高いソフトウェアを書く 以下のようになります。 とはて、きません。したがって , 第 3 の主張は 移植されています。この事実を否定するこ 本来意図していなかったて、あろう環境にも からぬ数のツールは MS ー DOS など開発者が て、の移植性が保たれています。さらに少な テクチャの CPU て、あっても , ソースレベル 動く環境て、あれば , まったく異なるアーキ ツールのほとんどは UNIX に類似した OS が ているのもまた偽りのない事実て、す。 GNU 群は , その大半が多くのマシンへ移植され 出されている数多くのソフトウェアツール しかし , たとえば GNU プロジェクトて、生み 移植性をもつわけて、はないと主張しました。 C て、書かれたすべてのソフトウェアが高い ことが予想されます。 ような言語は汎用言語としては使用てきな う。もちろん例外もあるて、しようが , その ことはかなり限定されたものとなるて、しよ するとすれば , おそらくその言語て、て、きる 性を保っことがて、きる「安全な」言語が存在 す。もし , どんな記述をしても完璧な移植 い実行効率の裏返してあると考えるべきて、 ログラムも書けるというのは , 自由度と高 狙っているのて、す。移植て、きそうもないプ 行効率と記述の簡潔さを両立させることを 制限しか課さないことて、 , 結果的に高い実 グラマに高い自由度を与え , 必要最小限の において , 処理系のインプリメンタとプロ するものて、はありません。 C はその基本設計 グ言語として劣っている」ということを意味 しかし , これが「 C すなわちプログラミン を書くことができる C では移植性のきわめて悪いプログラム

ならないという場合てあれば , MS ー C コンパ チの標準ヘッダを用意する方法もあります。 たとえば前述の alloc. h を malloc. h としてコ ヒ。ーしてやれば , malloc. h を #include してい るソースがきても問題なくコンパイルて、き るわけて、す。ただし , このようなことをす ると , 逆に自分の環境からほかの人の TCC の環境へ移植をする場合に問題を引き起こ しかねません。知らず知らずのうちに TCC の「標準」て、はないへッダを # include してしま ったりするからてす。この手法を , 使用す る際には注意が十分必要てす。 ライフラリ関数の問題 この問題をさらに細かく分けると , 次の ようなります。 ① A 環境では用意されていなかった関数や 変数が B 環境では存在するために外部シ ンポル名がクラッシュする ② A 環境では用意されている関数が B 環境 には存在しない ③ A 環境と B 環境で同名の関数カ簿在する が , 引数の順序や期待している値が異 なる。あるいは , 微妙に仕様や動作が 異なる このうち①は PART2 の 1 ー 15 て、お話したの て、繰り返しません。②については PART2 の 2 ー 15 て、お話しましたが , 若干補足します。 各処理系に , MS-DOS のシステムコール (INT 21H ) のファンクションリクエストが 提供している機能を直接呼び出すライプラ リ関数がいくつか用意されています。例と して MS-DOS のファンクションリクエスト 0x3d によるファイルのオープンをあげる と , TabIe 4 のようになっています。 内部的には同じファンクションリクエス トを呼び出すにもかかわらず , 各コンパイ ラによってこれだけ差が出ています ( LSI が MS ー C と同じなのは , 意識的に仕様を合わせ ているからだそうて、す ) 。しかし , このよう な違いがあれば移植の際にコンパイルエラ ーなり , リンクエラーなりが発生しますか ら , そこて、気がっきます。そして必要に応 じて関数の意味を調べて , 同じ働きをする 関数と置き換えたり , あるいは自作したり するとか , 名前がクラッシュした場合には 適宜名前を付け替えりすることて、 , 多くの 場合はしのぐことがて、きます。 ③の問題の例をあげてみます。 far ポイン タから , セグメント値とオフセット値を取 り出すためのライプラリ ( 多くのコンパイラ て、はマクロ ) として , FP SEG と FP OFF と いうべアが de facto standard となっていま す。これらのライプラリの実装方法はおお よそ Fig. 5 の 3 種類て、す。 Fig. 5 ①の 2 番目のアプローチは , 結局引 数に渡された 32 ビットのポインタ「値」を上 位の 16 ビットと下位の 16 ビットに分けるも のて、す。ところが 3 番目の手法て、は引数は「 far のポインタ変数」て、なければなりません。か っ , マクロに渡した引数に単項の & が適用さ れますから , これが適用可能て、あるオプジ ェクトてなければこのマクロは使えません。 具体的には register 宣言したポインタ ( しか し ,far ポインタを register 宣言することに意 味があるかどうかは疑問てす ) とか , far ポイ ンタ変数に定数を加減算したような「 far ポイ TabIe 4 MS ー DOS のファンクションリクエスト Ox3d によるファイルのオープン 処理系 MS-C5 MS-C6 LSI TCC LAT 68 C MAGAZINE ファイルのオープン 1991 5 int dopen(char *path, int *mode) ; int —open (const char * path, int mode) ; unsigned -dos—open(char *path, unsigned mode, int *handle) ; unsigned -dos—open(char * path, unsigned mode, int *handle) ; unsigned —dos—open(cha 「 *path, unsigned mode, int *handle) ; ンタ型の rvalue 」の場合て、す。ちなみに れらのマクロ / 関数に far て、はなく near のポイ ンタを渡したらどうなるのてしようか。 れは実現手段にあまり関係なく , うまくい く場合もあり , いかない場合もありて , い ずれにしてもあまり好ましいコーディング て、はありません。 しかしながら , 引数への制限事項や要求 する型などの違いて、エラーが出るようなイ ンコンパチビリティはまだ罪が軽いほうて、 す。移植の際にいちばん怖いのは「 Quiet change 」てす。これは ANSI C の規格理由書 (Rationale) に使われてる用語て、 , 「古いソー スをコンパイルしてもエラーは発生しない が , 動作が異なってしまうような解釈 ( 意味 ) の変更」をさします。移植の場合には「 Quiet difference 」と呼ぶべきてしようか。処理系 間て、 , ェラーにはならないが実際の実行結 果が異なるという差異がある場合 , ほかの 環境て、は正しく動作しているソースが , 特 定の環境ては動かなくなってしまうという 不都合が生じるのて、 , これはきわめて危険 て、あるといえます。 さすがに ANSI て、定められた標準ライプラ リにおいては , ほば互換性がとれているよ うて、すが , MS ー DOS 用のローカルな関数て は食い違う場合もあります。有名なところ て、は cprintf がスクリーンコントロール用の ェスケープシーケンスを解釈してくれるか どうかという問題があります。 MS ー C ては解 釈しますが , TCC て、は解釈しません。 また , これは MS ー DOS 上だけに限ったこ とて、はありませんが , ライプラリの仕様の 微妙な差異と「ずばら」なコーディングスタ イルが組み合わされると , 深刻な問題が起 こります。先ほどは MS-DOS のファンクシ ョンリクエスト 0x3d によるファイルオープ ン関数を取り上げましたが , ほかにも UNIX 互換の open 関数 ( UNIX てはシステムコール ) が用意されています。これは次のようなプ ロトタイプだと考えられます。 int open(char * path, int Oflag, 可変引数宣言になっているのは 3 番目の引

解ー加れ e ⅳ Quick C, MS-C Ve 「 6 ℃環境で学ぶ。 劭 0 可 独学より大学 : ソフトウェア開発のさまざまな分野で標準プログラミンク言語となった C 言語。 Windows3.0 や MS OS / 2 のプログラミングに おいても C 言語は必要不可欠なものです。セミナーでは Windows3.0 や MS OS / 2 上のアプリケーションを作成したい方、また既 存のプログラムを C 言語で書き換えたい方などを対象に、 C 言語の基礎から応用まで実習中心に学ぶことができます。 下記コースも 好評開催中 ・ Windows コース プレゼンテーション・マネージャコース ・ LAN マネージャコース ・テ、ノヾイスドライノヾコース ・ OS/2 コース これから C 言語を始めようとする方を対象に、 C 言語の C 言語の特徴である、関数、制御構造、ホインタ、構造 基本的な文法からわかりやすく解説します。統合環境を 体についてプログラムを作成しながら詳しく解説します。 持つ Quick C を使って理解を深めます。 セミナは、最新の MicrosoftC Ver6.0 を使用して実施 いたします。 ■期間 : 2 日間 一期間 : 3 日間 ・受講料 : 6 万円 ( 税別 ) ■受講料 : 9 万円 ( 税別 ) ■内容 : C 言語の書式、変数の使い方、画面 ■内容 : 配列、ポインタ、文字列、構造体、 表示方法、キーポード入力、関数、制 PWB の統合開発環境 御文、 Quick C での環境設定等 環境設定、開発手順、デバッグ方法 解ー ・お問い合せは 富士ソフトウェア株式会社 MIJ 教育センター TEL03-3452-7722 ( 直通 ) FAX 03-3798 ー 0599 。士ソフトウェア株式会社 MIJ 教育センター 〒田 8 東京都港区三田 3-4 ー 3 三田第一長岡ビル 〒 0 東京都新宿区西新宿 7 ー 5 ー 25 K ビルディング く資料請求番号 1 82 〉

C プロ ク、一 フム。 特集 を int に typedef するか , #define することて、 くは unsigned int へ型変換されるのて、す。 す。しかし , これは「関数の戻り値の型」を char が符号つきて、あれば , 0X80 は符号拡張 指定する void に関してはそれなりにうまく され int になります。するとこれは一 128 にな いきますが , それ以外の void に関しては田 ってしまいます。ー 128 と 0X80 は比較しても ッじ、 void は V7 て、導入されました。そのときの 等しいはずはありません。 わしくありません ( ただし関数の戻り値の void void は「値を返さない関数」を指定する意味 を int に置き換えると , コンパイラによって そのため , このようなコーディングをす と , ( void ) て、キャストする関数を呼び出した は「戻り値が int と宣言されているのに , 実際 ると , char が符号なしの環境て、は期待どお 結果の値を明示的に捨てることを指示する には値が返されていない」というような警告 りに動作するのて、すが , char が符号っきの ためのものて、した。その後 ANSI C て、「総称 がて、ることがあります ) 。とくに問題なのは 環境て、は期待どおりに働きません。これは , ポインタとしての void * 」と , パラメータタ 元のソースが void * の特性を利用してキャ とくにシフト JIS や EUC など , MSB が 1 て、あ イプリストの導入にともなう「パラメータタ ストを省略しているような場合て、す。した るような文字コードを多用するシーンて、は イプリストに用いて , 引数がない関数を示 がって , 移植性を考えるならば void * は避 切実な問題になります。 wchar t などという す void 」という , 都合 3 種類の使い方が可能 けたほうが賢明て、す。 型が ANSI C て、導入されることになりました になりました。 が , 現時点て、まだまともにサポートしてい / * 3 種類の void * / るコンパイラはないに等しく , ましてや移 植性を考えると当面この型を使うことは避 VOid foo(void) けるべきて、しよう。結局 , MSB が 1 になるよ K & R の時代から , C て、は char 型が符号っ うなコードを取り扱う場合には以下の三つ きとして取り扱われるか , 符号なしとして の解決方法に頼ります。 取り扱われるかは処理系依存の項目て、した。 ① 0xff でマスクする K & R の文法の範囲内て、ソースを記述する ANSI C になって以来 , signed char と un ② char 型ではなく , unsigned char 型を使 という基本方針に従うかぎり , これらの void signed char と記述することて、明示的に char 用する ③ (unsigned char) でキャストする はすべて使えないことになります。それて、 の符号をコントロールて、きるようになりま もとくに困ることはありません。強いてい した。しかし , 依然としてただの (plain)char このうち , いちばんオーソドックスなが えば , void * が使えないと , これを char * という型が残っていて , これの符号の取り ら応用範囲が広いのは①て、しよう。厳密に て、代用することになりますが , ANSI C コン 扱いについては処理系依存になっています。 いえば , K&R の時代には unsigned char は パイラを使う場合には , char * を引数とし この問題はかなり深刻な結果をもたらす場 なかったということもあります。いちいち て受け取るような関数に対して , それ以外 合があります。 マスクを書くのはたいへんてすから , environ. の型へのポインタ ( て、 , かっ void * 型の値て、 もっとも端的なものとしては 0X80 以上の h の中て、次のようなマクロを定義しておくと も 0 て、もない値 ) を実引数として渡そうとす 整定数と char の変数 ( オプジェクトというほ よいて、しよう。 る場合には必ず ( char * ) て、キャストしなけれ うがより正確て、す ) の値を比較するようなシ #define CTOI(c) ((c) & Oxff) ば , コンパイル時に警告がて、てしまうとい ーケンスて、す。 もちろん , このマクロは char が signed の 環境用て、す。 char が unsigned の環境て、は何 う制約があります。 Char c; しかし , この制約はむしろ望むところて、 もする必要はありません。なお , 0xff という す。こと関数の仮引数と実引数間に関して 定数を書いているということは , char のビ は , 暗黙の型変換はつねに避けるべきて、し ット幅を 8 ビットと仮定していることになり よう。後て、詳しく述べますが , 関数の引数 ます。この仮定は必ずしもすべての環境に に関しては積極的にキャストして , 型を一 おいて成り立つものてはありません。しか 致させて受け渡すべきて、す。 この例て、 , if 文の条件は必ず成立しそうに し , いずれにせよ environ. h は環境依存部分 なお , void を多用して書かれているソー 田いがちて、すが , そうて、はありません。 C て、 を定義するためのものてすから , この部分 は , char, short, bit field のオプジェクト スを K & R 環境 ~ 移植する場合には , カ第り はこれても問題ありません。 の困難が生じます。 K & R 環境て、 void をエミ に関する演算に際して lntegral promotion また , 処理系によってはデフォルトの char ュレートするもっとも一般的な方法は , void ( 整数格上げ ) が起こり , 型に応じて int もし 型の符号の取り扱いを変えることがてきる 特集 C プログラム移植入門 49 VOid 1 ー 4 。 char の符号 VOid *p; 0x80 ; C 0x80)

初めて表計算ソフトを使う人のために、理解しにくい部分を徹底解説 5 / 1 号 定価 560 円 ( 税込 ) 新入社員に贈る表計算ソフト入門 ユーサーの疑問に答える PC トラフルガイド 安全運用のための無停電電源装置 F-I DATABOX / リードレックス 第 2 特集 テストルーム 1 ソフトウェア最前線 0 アプリを使いこなす MS ー DOS ・自信かっく M 旧 ES マクロ 東芝 DynaB00k / J ー 3100 シリーズアプリケーション活用誌 アプリケーション 徹底活用シリーズ 5 特別付録、一 3.5 インチティスク DynaBase ASKA 月号 特別定価 640 円 ( 税込 ) DynaBase ASKA テータベースの基本操作から応用までを、サンプルテータにもとづいて紹介 するとともに、テータベースか与えてくれる環境の実態をレポート 特集 Windows3 ℃環境を探る 4 月に発売か決定した東芝 Windows3.0 環境Øü心に迫る DynaB00k386SXvsJ-3100ZS ・“最近”ネットワーク事情 ・誰にでもできるテータコンバート実例集 ・そりゃないせ / Dyna ・企業ユーサーレポート ソフトバンク出版事業部 SOFT 〒 108 東京都港区高輪 2 ー 19 ー 13NS 高輸ピル BANK TEL : 03 ー 54 一 1360 SPECIAL REPORT

1 てきません。しかし , 作業が進めば , マル チスレッド環境を活用てきるツールキット も開発されるだろうと思います。 C と次世代ツールキットの設計上の問題点 を洗い出すプロジェクトがスタートしたば かりて、す。そのプロジェクトては , マルチ スレッドが考慮すべき重要なことがらてあ ることは明らかて、す。 理想的な フラットフォーム OSF との関係についてお尋ねします。 Motif は x Window と密接な関係をもってい るように見えますが , OSF とは開発の上で 私たちはマルチスレッド環境を考えると 実際には , X ライプラリのもっとも低水準 共同歩調を取っているのでしようか ? きに , 単に処理効率を上げるということよ な部分は , マルチスレッド環境て、も使える ScheifIer OSF は X コンソシアムの会員て り , 内部負荷を高い水準て維持することに ようになっており , そのレベルて X を使った す。 主眼をおいています。実際には , 内部負荷 研究者は過去に何人もいます。ただし , M 。 tif 現在 , AT&T の UI(UNIX lnternational) を失わずに並行処理をサポートすることは のような X ツールキット , すなわち XT とそ と ,x Wind 。 w に包含すべき標準の議論に関 こが焦点になるわけてす。 の上のツールキットの部分は , もともとシ 連して何かやりとりはありますか ? て、きません。 同時に処理効率も上げることがてきれば , ングルスレッド環境のために設計されてお ScheifIer AT&T, Sun といた UI の会員は さらによいというところてす。 り , マルチスレッド環境を活用することは X コンソシアムの会員てすが , UI 自体はコ ンス以上売れている。 M0tif には , 年内に新 テムのための GU し M0tif を発表した M0tif X Window と バージョンリリースの計画がある。新バー は , Ⅶ T がネットワーク化された高速 WS の OSF ジョンは , 「国際化」の面で大きく改善さ ために開発したグラフィカル操作環境 , X れ , 日本をはじめとする英語以外の言語圏 , Window システムのもとで動作するように設 米国以外の国に向けた移植が容易になる。 計されているが外見的には Microsoft と旧 M U N Ⅸは AT & T ベル研究所で開発された OS が共同開発しえ PM ( プレゼンテーシ = ンマ OSF ビジネス分野担当マネージャで , この革 だが , 開発元の AT & T の影響力を嫌った 新的な GUI の未来戦略のキーマンである Cra ig ネージャ ) と非常によく似ている。 Motif は , 旧 M, DEC などの有名企業グループは , 数年 Lamont 氏に OSF の未来を語ってもらった。 OSF の会員も含めて多くの人たちカくほど 前に新しい組織 , オープンソフトウェアフ の成功をおさめた。そして , UN Ⅸに限らず アウンデーション ( OSF ) を発足させた。 OSF 広まりつつある Motif 世界 ほとんどあらゆる OS ( この中には DOS も含ま の使命は , AT & T が普及させている UN Ⅸ れる ) で高い人気を誇る GU にして現在に至 System V に対抗すべき「新しい UNIX 」を っている。 OSF と X Window コンソシアムの公的 , 開発することである。 OSF は , 旧 M 版の UNIX OSF/Motif アプリケーションはこれまでに 技術的な関係についてお聞かせください。 である AIX をベースとしてこの新しい 約 300 種類開発され , ' 91 年末には 1500 種近く Lamont 公的には , OSF は X Window コン UNIX, OSF / 1 の仕様をリリースしたが , 現 まで増えるものと見込まれている。当初 , ソシアムの会員という立場て、あり , ほかの 在はカーネギーメロン大学で開発されたマ OSF はこの時期までに Motif の販売数を 20 万 会員とともに X の将来の方向を決めるための ルチプロセッサシステム MACH を取り込む 6000 ライセンスまで伸ばすことを目標とし コンソシアムの作業を助けています。また , 形で機能拡張作業に入っている。 ていたが , 実際に販売されたライセンス数 Motif は MIT 全体て、ほば独占的に使われてお OSF の最大の目標が新しい IJN Ⅸの開発に は 30 万を越えた。また , OSF が発表した数字 り , 選ばれたユーザインタフェイスという あることに変わりはないが , 2 年ほど前 , OSF によれば , 開発者向けシステムも 5 万ライセ の会員企業は , OSF / 1 オペレーティングシス 地位を築いています。 コラ乙 18 C MAGAZINE 1991 5

ク、一 パーコンヒ。ュータに至るまて、 , 広いスペク トルのマシンのための多数のソフトウェア プロジェクトが C て、記述されています。そし て , 開発責任者にプログラミング言語とし て C を選択した理由を問いただすと , 「移植 性がよいのて、 , 将来にわたって複数のソフ ト・ハード環境への応用が期待て、きるから」 という回答が理由のひとっとしてあげられ るのは茶飯事となっています。 しかし , 筆者はそれらの開発担当者が実 際どれほど移植性を真剣に考慮しているの だろうかと不安を感じます。 C は決して魔法 のプログラミング言語て、はありません。後 て、詳しく述べますが , C て、コーディングしさ えすれば , すべてのプログラムが自動的に 移植可能なものになるわけて、はありません。 本特集て、は , C における移植性に関して多数 の観点から考察し , どのような点が移植性 を低下させるのか , またどのようにすれば それらの問題を回避て、きるのかを考えてみ ます。 個人差はあるて、しようが , 一般にプログ ラミングというのは決して容易な作業て、は ありません。特定のマシンて、 , 特定の OS の 下て、 , 特定のコンパイラを使うと限定して も , 意図どおりに動作するプログラムを作 るのはたやすいことて、はありません。まし て , 移植性の高いプログラムを作るのは通 常たいへん困難な作業となります。それは , 数多くの環境と言語処理系の詳細な仕様に 関する広範な知識が必要とされるからて、す。 すべてにわたる知識を有することは現実的 に不可能なことて、すから , ある程度は想像 て補わねばなりません。本稿はそのような 想像力を働かせるためのヒントとなること を願って , 移植の際に落とし穴となりやす い間題点を論じ , 解決策の方向性を示そう と努めました。 それては本題に入る前に こて、いう「移 植性」という言葉をもう少し詳細に定義して おきましよう。もちろん用語集を作るのが 目的てはありませんから , あくまて、今回の テーマに適切なバックグラウンドを共有す 特集 C プロ るための定義て、あると考えてください 移植とは ある環境で動作しているソフトウェアを 別の環境でも同様に動作させること 多くの場合 , 移植には新しい環境にソー スを持ち込んて、再コンパイルするという作 業が伴います。この場合はソースレベルて、 の移植と呼びます。通常 , 単に移植という とソースレベルの移植を指します。このほ かに ( 少なくとも ) バイナリレベルの移植性 とデータの移植性が考えられます。 バイナリレベルの移植性とはコンパイル 後 , もしくはリンク後のファイルをほかの 環境に持ち込んて、動作させることて、す。 のようなことが可能なのは , おおむね同一 の CPU アーキテクチャのマシン間て、 , かっ 同一あるいは類似の OS を使用している場合 だけと思ってよいて、しよう。したがって , 以下て、はバイナリレベルの移植はテーマの 対象外にします。 またデータの移植性とは , プログラムて、 はなく , データ ( 多くの場合ファイル ) を別 な環境へ持ち込む場合を指します。とくに バイナリデータの場合には種々の問題が発 生しやすいのて、す。これに関しては後て、少 し触れます。 移植性とは 移植に要するソフトウェアの修正の多少 で評価する尺度である 移植の際には大なり小なりソースやデー タの修正が必要になるのが普通て、す。修正 が皆無て、よければ , そのプログラムは最良 の移植性をもっていることになります。本 稿て、は , そのような状態を「移植可能」と呼 ぶ場合があります。これは何もそれ以外の 場合に「移植不可能」て、あるという意味て、は なく , 修正の必要なく移植て、きるというこ とを表しています。 一般にはある規模以上のソフトウェアて は , なんらかの変更が必要て、す。全体の修 正の程度 ( 分量 ) て、移植性の良否を評価する ことになります。移植性を評価する絶対的 フム。 特集 C プログラム移植入門 41 があります。それらの言語の移植性に関す 世の中には数多くのプログラミング言語 移生が高いのか 当に ず変更しなくてはなりません。 マシン ( CPU ) 依存なのて、 , その部分はかなら しかしコンパイラは , 本質的にターゲット 以下の話が適用て、きる点は多いと思います。 ら , コンパイラ自身の移植性に関しても , を借りつつ C て、記述するのが半ば常識て、すか C コンパイラ自身も , lex や yacc などの助け の移植性のことて、はありません。もっとも ます。 C 言語の処理系 ( コンパイラ ) それ自身 フトウェアの移植性」という意味て、使ってい いますが , これは「 C によって記述されたソ なお , 「 C の移植性」という表現を頻繁に用 コーディングの方針が違ってきます。 のて、しようか。それぞれの場合て、 , 自ずと 場合にも移植性を確保しなければならない とも , 今後の C のさらなる文法変更があった パイラに対してだけなのて、しようか。それ 最後に , 移植性を確保するのは現在のコン サポートしなければならないのて、しようか。 ようか。コンパイラの文法はどの範囲まて、 OS の上に移植てきなければならないのて、し なけれならないのて、しようか。どのような はいったいどんなマシンの上に移植可能て、 済的な方針となります。そのソフトウェア うえて、必要十分な努力を行うというのが経 性を確保すべきて、あるかを見定めて , その 要します。したがって , 「どの範囲て、」移植 せん。ただしその場合 , 少なからず労力を 保て、きるならばそれにこしたことはありま プログラムを作成する場合 , 移植性を確 ります。 ど , 修正の必要な箇所は増加する傾向にあ ェアの機能を有効に利用していればいるほ に凝ったものてあればあるほど , ハー アの規模が大きくなればなるほど , 機能的 断基準に基づいています。一般にソフトェ な基準はありません。あくまて、主観的な判

ソフトバンクの新刊 桐 Ve 3 事曲 ′、 VO い会話処理編 アルシープ著 定価 2 , 800 円 桐 Ver. 3 の「会話処理」を事典形式で解説したもの。既刊書「桐 Ver. 3 Quick Reference 」の該当部 よりもさらに詳細な記述を望む方への一冊。 ポケット版 MS-C 阨に 6.0 ー関数リファルス 高瀬典明著 定価 2 , 000 円 MS-C Ver. 6.0 のライプラリ関数について、読者の使い勝手を主眼として作成された新しいタイ プのリファレンス。ポケットサイズの形態により、手元で手軽にひけるハンデイタイプ。 MS-DOS OS / 2 コマンドブック 坂本浩・中平弘文共著 定価 3 , 800 円 MS ー IDS 、 OS / 2 の両 OS にまたがるコマンド事典、ファイル事典。単なるコマンド、ファイル解 説にとどまらず、環境構築法まで詳しく解説。 MS-DOS 環境整備術 3 Newton-98 西田雅昭・桑島肇共著 定価 1 , 900 円 「最も優れたファイル管理ソフト」「エコロジーを越えた」と評判の Ne 。 n ー 98 本邦初の解説 書。メーカー提供の最新情報も満載された一冊。 SX - Ⅷ NDOW プログラミング 吉沢正敏著 定価 4 , 500 円 X6 開にマルチタスク・マルチウインドゥ環境をもたらした SX ーⅥ NI 刈、」 : でプログラミン グするにはどうすればいいか。内部解析にもとづいたプログラミングの実例を示した一冊。 Wo 「 ks カイド ビギナー編 佐藤イッキ著 定価 2 , 300 円 統合型ソフト「 Works 」の文書作成・表計算・データベース・通信という 4 つの機能について、基本 操作から統合操作までをやさしく解説。

ク、一 かありません。同様のエラーに次のような ものがあります。 int ba 「 (i) 「 eturn fOO(), IO),• 特集 C プロ フム この例は ANSI スタイルて、はなく , Old style て、記述されています。この場合 , 引数 に関する情報 ( パラメータタイプリスト ) を 書くことがて、きず , 関数 f00 が要求している 引数がなんて、あるかをコンパイラが知るす べはありません。そのため関数 bar の内部て、 f00 を呼び出すときに , 実引数として渡され る i と 10 は default argument promotion を 受けますが , 両者はともに int て、あるため , とくに型変換はされず , そのまま渡されま す。しかし , 関数 f00 が , たとえば別のファ イルの中て、 ( 1 。 ng , long) という引数を受け取 るようにコーディングされていたらどうな るて、しようか。あるいは , (int, long ) の場合 て、も , (long, int ) の場合て、も同じて、す。実際 に渡されているのは ( int , int ) て、すから , そ れらはいずれも型が一致していない なります。それにもかかわらず , これまた , int と long が同じサイズの環境て、は動作上の 支障にはなりません。両者のサイズが異な る環境て、のみ問題が生じるのて、す。 この問題は古くから有名て、 ,lseek や fseek などの関数が long を要求しているのに , そ こに int を渡してしまうことてバグを出して しまうケースがほうばうて、報告されていま す。それらは int と long のサイズが異なる環 境て、は , 明らかに動作が期待どおりてなく なるためにすぐに気づきますが , 両者が同 じ環境ては一見正常に動くために見過ごし がちて、す。 ANSI C 環境ては , パラメータタイプリス トつきの宣言 ( 関数プロトタイプ ) を用いる ことて、この間題は解決します。しかし , ま だまだ古い文法の C しか存在しない環境もあ ります。関数プロトタイプによる暗黙の型 変換に頼って , long を期待している引数に int の値を渡すという行為は , 移植性を確保 する場合には避けなくてはなりません。明 示的にキャストされるべきて、す。 さらに関数を直接その名前を使って呼び 出すのて、はなく , 関数へのポインタを使っ て呼び出す場合には , ANSI C コンパイラを 使っていても , ついついパラメータタイプ リストをつけるのを省略しがちて、す。 ・パラメータタイプリストを省略した宣言 int (*fpcO)( ) ; ・パラメータタイプリストを付加した宣言 int (*fpcl)(long, long); fpc0 のように宣言をしている場合には , ANSI C を用いていても , やはり同様の問題 が生じるのはいうまて、もありません。 たとえば , i という int の変数があったとし て , この下位の 4 ビットを強制的にゼロにし たいケースがしばしば発生します。このよ うな場合によく見受けられるのは次のよう なコーディングて、す。 i & = 0xfff0 ; すなわち , 16 進の FFFO と「ビットごとの AND 」をとることて、目的を達しようというわ けて、す。 int のサイズが 16 ビット以下て、ある 環境にかぎれば , もちろんこれて、動作しま す。 ANSI C の規格上は , int のサイズは最 低 16 ビットあることが要求されています。 しかし , もちろんそれ以上のケースもある わけて、す。もし , int のサイズが 16 ビットよ りも大きいとき , たとえば 32 ビットあるい はそれ以上てあると , 上記のコーディング は好ましくありません。とくに i の値が負て あった場合に決定的な問題となります。す なわち 16 ビットより上位の部分のビットも 落とされてしまうために , 符号ビットが反 転し , 結果として正の値に変化してしまう からてす。この場合 , 次のようにコーディ ングするほうが賢明てす。 i & = -0xf : int のサイズの仮定 こて、使った演算子「 ~ 」は「ビットごとの 特集 C プログラム移植入門 57 main( ) #include <stdio. h> 難かもしれません ) 。 ることを考えると , キャストするほうが無 チェックの際に警告を出されないようにす ャストしても実害はありません。 lint による ことが保証されているからてす ( もちろんキ に必要ありません。自動的に型変換される ムの断片ては , (FILE * ) のキャストはとく そうなのてす。当然 , 次のようなプログラ これは K & R の時代から ANSI C に至るまて 比較することがてきると保証されています。 可能てあり , また , あらゆるポインタ値と インタ変数へ ( 警告なして ) 代入することが そして , NULL に関してだけはあらゆるポ キャストしたものて、もよいとされています。 るか , あるいは ANSI C てはそれを void * に り , 具体的な値は整定数 0 ( もしくは 0L ) てあ というのは , プリプロセッサシンポルてあ ないのは , NULL に関してて、しよう。 NULL しかし , いちばん注意をしなければなら なります。 イズが原因となるバグに泣かされることに いて、プログラムしていると , ポインタのサ いる場合ても , 関数プロトタイプを用いな 合には大いにあり得ます。 ANSI C を用いて ( ゼロて、はありません ) のて、すが , 古い C の場 グラムがこの混同をしている可能性は低い なったため , ANSI C べースて開発したプロ int とポインタの間の型変換は黙認されなく ましくありません。 ANSI C になって以来 , 一般に , int とポインタの混同は移植上好 ポインタのサイズ に任せている点がポイントてす。 マが指定しているのてはなく , コンパイラ してくれます。ここて、 , int の幅はプログラ 位 4 ビット以外はすべて 1 の int の値」を生み出 NOT 」を意味します。したがって , 0xf は「下