Alessandro Bonazzi
e075990ed3
Files correlati : Commento : Aggiunto il preprocessore c++ mcpp per sostituire il compilatore nella compilazione delle maschere.
4585 lines
360 KiB
HTML
4585 lines
360 KiB
HTML
<html>
|
||
<head>
|
||
<meta http-equiv="Content-Type" content="text/html; charset=EUC-JP">
|
||
<style> pre {color: navy} tt {color: maroon} </style>
|
||
<style> table {border-collapse: separate; border-spacing: 0px; empty-cells: show; background-color: #f0f0ff} </style>
|
||
<style> th, td {text-align: left; padding-left: 15px; padding-right: 15px} </style>
|
||
</head>
|
||
<body>
|
||
<div align="center">
|
||
<h1>MCPP-MANUAL</h1>
|
||
<h2>== How to Use MCPP ==</h2>
|
||
</div>
|
||
<div align="right">
|
||
<h4>for V.2.7.2 (2008/11)<br>
|
||
松井 潔 (kmatsui@t3.rim.or.jp)</h4>
|
||
</div>
|
||
<div align="center">
|
||
<h2>== 目次 ==</h2>
|
||
</div>
|
||
<dl><dt><a name="toc.1" href="#1">1. 概要</a>
|
||
<dd><a name="toc.1.1" href="#1.1">1.1. ＯＳや処理系を選ばない portable なソース</a>
|
||
<dd><a name="toc.1.2" href="#1.2">1.2. 正確な Standard C モードに加えてその他の各種モードも</a>
|
||
<dd><a name="toc.1.3" href="#1.3">1.3. このマニュアルの表記法</a>
|
||
<br>
|
||
<br>
|
||
<dt><a name="toc.2" href="#2">2. 起動時のオプションと環境設定</a>
|
||
<dd><a name="toc.2.1" href="#2.1">2.1. <b>mcpp</b> 実行プログラムの２種類のビルドと５つの動作モード</a>
|
||
<dd><a name="toc.2.2" href="#2.2">2.2. 起動時のオプションの指定法</a>
|
||
<dd><a name="toc.2.3" href="#2.3">2.3. 共通のオプション</a>
|
||
<dd><a name="toc.2.4" href="#2.4">2.4. <b>mcpp</b> の動作モードによるオプション</a>
|
||
<dd><a name="toc.2.5" href="#2.5">2.5. 特定の処理系以外の処理系に共通のオプション</a>
|
||
<dd><a name="toc.2.6" href="#2.6">2.6. 処理系ごとのオプション</a>
|
||
<dd><a name="toc.2.7" href="#2.7">2.7. 環境変数</a>
|
||
<dd><a name="toc.2.8" href="#2.8">2.8. Multi-byte character の encoding</a>
|
||
<dd><a name="toc.2.9" href="#2.9">2.9. ワンパスコンパイラで <b>mcpp</b> を使うには</a>
|
||
<dd><dl><dt><a name="toc.2.10" href="#2.10">2.10. 統合開発環境で <b>mcpp</b> を使うには</a>
|
||
<dd><a name="toc.2.10.1" href="#2.10.1">2.10.1. Visual C++ の IDE で <b>mcpp</b> を使う方法</a>
|
||
<dd><a name="toc.2.10.2" href="#2.10.2">2.10.2. Mac OS X / Xcode.app で <b>mcpp</b> を使う方法</a></dl>
|
||
<br>
|
||
<dt><a name="toc.3" href="#3">3. 拡張機能と互換性</a>
|
||
<dd><dl><dt><a name="toc.3.1" href="#3.1">3.1. #pragma MCPP put_defines, #pragma MCPP preprocess 等</a>
|
||
<dd><a name="toc.3.1.1" href="#3.1.1">3.1.1. ヘッダファイルの pre-preprocess</a></dl>
|
||
<dd><dl><dt><a name="toc.3.2" href="#3.2">3.2. #pragma once</a>
|
||
<dd><a name="toc.3.2.1" href="#3.2.1">3.2.1. ヘッダファイルに #pragma once を書き込むツール</a></dl>
|
||
<dd><a name="toc.3.3" href="#3.3">3.3. #pragma MCPP warning, #include_next, #warning</a>
|
||
<dd><a name="toc.3.4" href="#3.4">3.4. #pragma MCPP push_macro, #pragma __setlocale 等</a>
|
||
<dd><dl><dt><a name="toc.3.5" href="#3.5">3.5. #pragma MCPP debug, #pragma MCPP end_debug, #debug, #end_debug</a>
|
||
<dd><a name="toc.3.5.1" href="#3.5.1">3.5.1. #pragma MCPP debug path, #debug path</a>
|
||
<dd><a name="toc.3.5.2" href="#3.5.2">3.5.2. #pragma MCPP debug token, #debug token</a>
|
||
<dd><a name="toc.3.5.3" href="#3.5.3">3.5.3. #pragma MCPP debug expand, #debug expand</a>
|
||
<dd><a name="toc.3.5.4" href="#3.5.4">3.5.4. #pragma MCPP debug if, #debug if</a>
|
||
<dd><a name="toc.3.5.5" href="#3.5.5">3.5.5. #pragma MCPP debug expression, #debug expression</a>
|
||
<dd><a name="toc.3.5.6" href="#3.5.6">3.5.6. #pragma MCPP debug getc, #debug getc</a>
|
||
<dd><a name="toc.3.5.7" href="#3.5.7">3.5.7. #pragma MCPP debug memory, #debug memory</a>
|
||
<dd><a name="toc.3.5.8" href="#3.5.8">3.5.8. #pragma MCPP debug macro_call</a></dl>
|
||
<dd><a name="toc.3.6" href="#3.6">3.6. #assert, #asm, #endasm</a>
|
||
<dd><a name="toc.3.7" href="#3.7">3.7. C99 の新機能（_Pragma() 演算子、可変引数マクロ等）</a>
|
||
<dd><dl><dt><a name="toc.3.8" href="#3.8">3.8. 処理系ごとの特殊な仕様</a>
|
||
<dd><a name="toc.3.8.1" href="#3.8.1">3.8.1. GCC, Visual C の可変引数マクロ</a>
|
||
<dd><a name="toc.3.8.2" href="#3.8.2">3.8.2. GCC の 'defined' の処理</a>
|
||
<dd><a name="toc.3.8.3" href="#3.8.3">3.8.3. Borland C の asm 文その他の特殊な構文</a>
|
||
<dd><a name="toc.3.8.4" href="#3.8.4">3.8.4. #import その他</a></dl>
|
||
<dd><dl><dt><a name="toc.3.9" href="#3.9">3.9. GCC の問題と GCC との互換性</a>
|
||
<dd><a name="toc.3.9.1" href="#3.9.1">3.9.1. FreeBSD 2 / kernel ソースのプリプロセス</a>
|
||
<dd><a name="toc.3.9.2" href="#3.9.2">3.9.2. FreeBSD 2 / libc ソースのプリプロセス</a>
|
||
<dd><a name="toc.3.9.3" href="#3.9.3">3.9.3. GCC 2 / cpp の仕様の問題</a>
|
||
<dd><a name="toc.3.9.4" href="#3.9.4">3.9.4. Linux / glibc 2.1 ソースのプリプロセス</a>
|
||
<dd><dl><dt><a name="toc.3.9.5" href="#3.9.5">3.9.5. GCC 2 で <b>mcpp</b> を使うには</a>
|
||
<dd><a name="toc.3.9.5.1" href="#3.9.5.1">3.9.5.1. <b>mcpp</b> のウォーニングを整理するには</a></dl>
|
||
<dd><a name="toc.3.9.6" href="#3.9.6">3.9.6. GCC 3.2 ソースのプリプロセス</a>
|
||
<dd><a name="toc.3.9.7" href="#3.9.7">3.9.7. GCC 3, 4 で <b>mcpp</b> を使うには</a>
|
||
<dd><a name="toc.3.9.8" href="#3.9.8">3.9.8. Linux / glibc 2.4 ソースのプリプロセス</a>
|
||
<dd><a name="toc.3.9.9" href="#3.9.9">3.9.9. Linux の stddef.h, limits.h, #include_next の問題</a>
|
||
<dd><a name="toc.3.9.10" href="#3.9.10">3.9.10. Mac OS X / Apple-GCC とシステムヘッダの問題</a>
|
||
<dd><a name="toc.3.9.11" href="#3.9.11">3.9.11. firefox 3.0b3pre ソースのプリプロセス</a></dl>
|
||
<dd><dl><dt><a name="toc.3.10" href="#3.10">3.10. Visual C++ のシステムヘッダの問題</a>
|
||
<dd><a name="toc.3.10.1" href="#3.10.1">3.10.1. コメントを生成するマクロ ?</a>
|
||
<dd><a name="toc.3.10.2" href="#3.10.2">3.10.2. Identifier 中の '$'</a></dl>
|
||
<br>
|
||
<dt><a name="toc.4" href="#4">4. 処理系定義の仕様</a>
|
||
<dd><a name="toc.4.1" href="#4.1">4.1. 終了時の status 値</a>
|
||
<dd><a name="toc.4.2" href="#4.2">4.2. Include directory のサーチパス</a>
|
||
<dd><a name="toc.4.3" href="#4.3">4.3. Header name の構築法</a>
|
||
<dd><a name="toc.4.4" href="#4.4">4.4. #if 式の評価</a>
|
||
<dd><a name="toc.4.5" href="#4.5">4.5. #if 式での文字定数の評価</a>
|
||
<dd><a name="toc.4.6" href="#4.6">4.6. #if sizeof (type)</a>
|
||
<dd><a name="toc.4.7" href="#4.7">4.7. White-space sequence の扱い</a>
|
||
<dd><a name="toc.4.8" href="#4.8">4.8. <b>mcpp</b> 実行プログラムのデフォルトの仕様</a>
|
||
<br>
|
||
<br>
|
||
<dt><a name="toc.5" href="#5">5. 診断メッセージ</a>
|
||
<dd><a name="toc.5.1" href="#5.1">5.1. 診断メッセージの形式</a>
|
||
<dd><a name="toc.5.2" href="#5.2">5.2. Translation limits</a>
|
||
<dd><dl><dt><a name="toc.5.3" href="#5.3">5.3. Fatal error</a>
|
||
<dd><a name="toc.5.3.1" href="#5.3.1">5.3.1. <b>mcpp</b> 自身のバグ</a>
|
||
<dd><a name="toc.5.3.2" href="#5.3.2">5.3.2. 物理的エラー</a>
|
||
<dd><a name="toc.5.3.3" href="#5.3.3">5.3.3. Translation limits と内部バッファのエラー</a>
|
||
<dd><a name="toc.5.3.4" href="#5.3.4">5.3.4. #pragma MCPP preprocessed に関するエラー</a></dl>
|
||
<dd><dl><dt><a name="toc.5.4" href="#5.4">5.4. Error</a>
|
||
<dd><a name="toc.5.4.1" href="#5.4.1">5.4.1. 文字とトークンに関するエラー</a>
|
||
<dd><a name="toc.5.4.2" href="#5.4.2">5.4.2. 完結しないソースファイルのエラー</a>
|
||
<dd><a name="toc.5.4.3" href="#5.4.3">5.4.3. Preprocessing group 等の対応関係のエラー</a>
|
||
<dd><a name="toc.5.4.4" href="#5.4.4">5.4.4. ディレクティブ行の単純な構文エラー</a>
|
||
<dd><a name="toc.5.4.5" href="#5.4.5">5.4.5. #if 式の構文エラー等</a>
|
||
<dd><a name="toc.5.4.6" href="#5.4.6">5.4.6. #if 式の評価に関するエラー</a>
|
||
<dd><a name="toc.5.4.7" href="#5.4.7">5.4.7. #define のエラー</a>
|
||
<dd><a name="toc.5.4.8" href="#5.4.8">5.4.8. #undef のエラー</a>
|
||
<dd><a name="toc.5.4.9" href="#5.4.9">5.4.9. マクロ展開のエラー</a>
|
||
<dd><a name="toc.5.4.10" href="#5.4.10">5.4.10. #error, #assert</a>
|
||
<dd><a name="toc.5.4.11" href="#5.4.11">5.4.11. #include の失敗</a>
|
||
<dd><a name="toc.5.4.12" href="#5.4.12">5.4.12. その他のエラー</a></dl>
|
||
<dd><dl><dt><a name="toc.5.5" href="#5.5">5.5. Warning (class 1)</a>
|
||
<dd><a name="toc.5.5.1" href="#5.5.1">5.5.1. 文字、トークンおよびコメントに関するウォーニング</a>
|
||
<dd><a name="toc.5.5.2" href="#5.5.2">5.5.2. 完結しないソースファイルのウォーニング</a>
|
||
<dd><a name="toc.5.5.3" href="#5.5.3">5.5.3. ディレクティブ行に関する各種のウォーニング</a>
|
||
<dd><a name="toc.5.5.4" href="#5.5.4">5.5.4. #if 式に関するウォーニング</a>
|
||
<dd><a name="toc.5.5.5" href="#5.5.5">5.5.5. マクロ展開に関するウォーニング</a>
|
||
<dd><a name="toc.5.5.6" href="#5.5.6">5.5.6. 行番号に関するウォーニング</a>
|
||
<dd><a name="toc.5.5.7" href="#5.5.7">5.5.7. #pragma MCPP warning, #warning</a></dl>
|
||
<dd><a name="toc.5.6" href="#5.6">5.6. Warning (class 2)</a>
|
||
<dd><a name="toc.5.7" href="#5.7">5.7. Warning (class 4)</a>
|
||
<dd><a name="toc.5.8" href="#5.8">5.8. Warning (class 8)</a>
|
||
<dd><a name="toc.5.9" href="#5.9">5.9. Warning (class 16)</a>
|
||
<dd><a name="toc.5.10" href="#5.10">5.10. 診断メッセージ索引</a>
|
||
<br>
|
||
<br>
|
||
<dt><a name="toc.6" href="#6">6. バグ報告等</a>
|
||
</dl>
|
||
<br>
|
||
|
||
<h1><a name="1" href="#toc.1">1. 概要</a></h1>
|
||
<p><b>mcpp</b> は Martin Minow の DECUS cpp を元に kmatsui（松井 潔）が全面的に書き直したＣプリプロセッサです。<b>mcpp</b> という名前は Matsui cpp という意味です。これはソースで提供するもので、各処理系で使うにはその処理系に合わせてソースに若干の変更を加えた上でコンパイルして <b>mcpp</b> の実行プログラムを作る必要があります。*1</p>
|
||
<p>このマニュアルでは、すでに特定の処理系に移植された実行プログラムの仕様を説明しています。さらに詳細を知りたい人、ソースから何らかの処理系に移植してみたい人は、ソースと <a href="mcpp-porting.html">mcpp-porting.html</a> というドキュメントを参照してください。<br>
|
||
これらのソース、ドキュメントはすべてオープンソース・ソフトウェアとして提供します。<br>
|
||
マニュアルの内容に入る前に、まず <b>mcpp</b> の特徴を紹介しておきます。</p>
|
||
<p>注:</p>
|
||
<p>*1 <b>mcpp</b> V.2.6.3 からは、コンパイルずみの何種類かのバイナリ・パッケージも次のサイトで提供するようにした。</p>
|
||
<blockquote>
|
||
<p><a href="http://mcpp.sourceforge.net/">http://mcpp.sourceforge.net/</a></p>
|
||
</blockquote>
|
||
<br>
|
||
|
||
<h2><a name="1.1" href="#toc.1.1">1.1. ＯＳや処理系を選ばない portable なソース</a></h2>
|
||
<p>Linux, FreeBSD, Windows 等の多くのＯＳをサポートしている portable なプリプロセッサであり、そのソースは Standard C (ANSI/ISO/JIS C) の処理系または Standard C++ の処理系でさえあればコンパイルできる広い portability を持っています。ライブラリ関数は古典的なものしか使っていません。<br>
|
||
各処理系に移植するためには、多くの場合、ヘッダファイル中のいくつかのマクロ定義を書き替えてコンパイルするだけですみます。最悪の場合でもソースファイルに数十行書き足す程度です。</p>
|
||
<p>Multi-byte character（漢字）の処理は日本の EUC-JP, shift-JIS, ISO2022-JP、中国の GB-2312、台湾の Big-5、韓国の KSC-5601 (KSX 1001) に対応しており、UTF-8 も使えます。Shift-JIS, ISO2022-JP, Big-5 の場合、コンパイラ本体が漢字を認識しない処理系では、<b>mcpp</b> がそれを補います。</p>
|
||
<br>
|
||
|
||
<h2><a name="1.2" href="#toc.1.2">1.2. 正確な Standard C モードに加えてその他の各種モードも</a></h2>
|
||
<p>Standard C 準拠の動作モードのほかに、K&R 1st. のモードや "Reiser" model cpp のモードもあり、さらには自称 post-Standard 仕様のモードまであります。C++ のプリプロセッサとして動作する実行時オプションもあります。<br>
|
||
Standard C モードは既存の多くのプリプロセッサと違って、規格を完全に実装しているつもりです。C90, C95, C99, C++98 のすべてに対応しています。Standard C プリプロセスの reference model となるものを目指して作ってあります。これらの規格のバージョンは実行時オプションで指定することができます。*1</p>
|
||
<p>ほかにいくつかの有用な拡張機能も持っています。マクロの展開機序や #if 式の評価機序をトレースする #pragma MCPP debug もあります。ヘッダファイルを "pre-preprocess" しておくこともできます。<br>
|
||
いくつかの有用な実行時オプションも備えています。ウォーニングのレベルを指定するオプションや、include directory を指定するオプション等です。<br>
|
||
ソースにどんな間違いがあっても <b>mcpp</b> は暴走したり見当外れなメッセージを出したりせず、正確でわかりやすい診断メッセージを出して適切な処理をします。移植上で問題となる点についても警告を発します。<br>
|
||
高品質でありながら、コードサイズは比較的小さく、メモリ消費も比較的少なくてすみます。<br>
|
||
詳細なドキュメントも付属しています。</p>
|
||
<p><b>mcpp</b> の欠点を強いて挙げれば、速度がやや遅いことです。GCC 3.*, 4.* / cc1 に比べると２倍から３倍の時間がかかります。しかし、Borland C 5.5 / cpp と同じくらいの速度で、ヘッダファイルの pre-preprocess の機能を使うともう少し速くなるので、特に遅いほうではありません。正確であること、portable なソースであること、少ないメモリでも動作すること等のためには、この程度の処理時間はやむをえないと考えています。</p>
|
||
<p>なお、プリプロセッサの Standard C 準拠度をテストするための検証セットである "Validation Suite for Standard C Preprocessing"、その解説およびそれを使ってテストした各種プリプロセッサの採点簿 cpp-test.html を <b>mcpp</b> とともに公開しています。これを見ると、「Standard C 準拠」と称する既存のプリプロセッサにいかに多くの問題があるかがわかります。</p>
|
||
<p><b>mcpp</b> は V.2.3 の開発の途中で、検証セット V.1.3 とともに、情報処理推進機構(IPA) の平成１４年度「未踏ソフトウェア創造事業」に新部 裕・プロジェクトマネージャによって採択され、2002/07 - 2003/02 の間は IPA の資金援助と新部ＰＭの助言のもとに開発が進められました。英語版ドキュメントもこのプロジェクトの中で、有限会社・ハイウェルに翻訳を委託し、それに私が修正とテキスト整形を加えてできあがったものです。*2<br>
|
||
<b>mcpp</b> はさらに平成１５年度にも「未踏ソフトウェア創造事業」に伊知地 宏 PM によって継続して採択され、V.2.4 への update 作業が進められました。<br>
|
||
その後も <b>mcpp</b> と検証セットはさらに改良の作業が続けられています。</p>
|
||
<p>注:</p>
|
||
<p>*1 Ｃ言語の規格としては ISO/IEC 9899:1990 (JIS X 3010-1993) が長く使われてきたが、1999 年には ISO/IEC 9899:1999 が採択された。ここでは前者を C90、後者を C99 と呼ぶ。前者は ANSI X3.159-1989 が移行したものなので、一般には ANSI C または C89 と呼ばれることもある。また、ISO/IEC 9899:1990 + Amendment 1995 を C95 と呼ぶことがある。C++ の規格は ISO/IEC 14882:1998 およびその正誤訂正版である ISO/IEC 14882:2003 で、この両者をここでは C++98 と呼ぶ。</p>
|
||
<p>*2 「未踏ソフトウェア創造事業」(Exploratory Software Project) の概要は次のところで知ることができる。</p>
|
||
<blockquote>
|
||
<p><a href="http://www.ipa.go.jp/jinzai/esp/"> http://www.ipa.go.jp/jinzai/esp/</a></p>
|
||
</blockquote>
|
||
<p><b>mcpp</b> V.2.3 以降のソースおよびドキュメントと検証セット V.1.3 以降は次のところに置いてきたが、</p>
|
||
<blockquote>
|
||
<p><a href="http://www.m17n.org/mcpp/"> http://www.m17n.org/mcpp/</a></p>
|
||
</blockquote>
|
||
<p>2006/04 に次のところに移った。</p>
|
||
<blockquote>
|
||
<p><a href="http://mcpp.sourceforge.net/"> http://mcpp.sourceforge.net/</a></p>
|
||
</blockquote>
|
||
<p><b>mcpp</b> の古いバージョンである cpp V.2.2 および検証セット V.1.2 はベクター社のサイトの次のところにある。dos/prog/c というディレクトリに入れられているが、MS-DOS 専用ではない。ソースは UNIX, WIN32/MS-DOS 等に対応している。</p>
|
||
<blockquote>
|
||
<p>
|
||
<a href="http://www.vector.co.jp/soft/dos/prog/se081188.html">http://www.vector.co.jp/soft/dos/prog/se081188.html</a><br>
|
||
<a href="http://www.vector.co.jp/soft/dos/prog/se081189.html">http://www.vector.co.jp/soft/dos/prog/se081189.html</a><br>
|
||
<a href="http://www.vector.co.jp/soft/dos/prog/se081186.html">http://www.vector.co.jp/soft/dos/prog/se081186.html</a><br>
|
||
</blockquote>
|
||
<p>これらのアーカイブファイル中のテキストファイルは、Vector のものは Windows に合わせて、改行コードは [CR]+[LF]、漢字は shift-JIS で encode してある。SourceForge のものは V.2.5 までは UNIX 系に合わせて改行コードは [LF]、漢字は EUC-JP である。V.2.6 からは [CR]+[LF] / shift-JIS の zip 版と[LF] / EUC-JP の tar.gz 版の２種類のアーカイブファイルを置くようにした。</p>
|
||
<br>
|
||
|
||
<h2><a name="1.3" href="#toc.1.3">1.3. このマニュアルの表記法</a></h2>
|
||
<p>このマニュアルはかつてはテキストファイルでしたが、V.2.6.2 からは html ファイルに変わりました。<br>
|
||
このマニュアルでは次のようにフォントを使い分けています。</p>
|
||
<ul>
|
||
<li><tt style="color:navy">source</tt>:<br>
|
||
<tt style="color:navy">紺色</tt>の等幅フォントは、ソースコードの断片およびコマンドラインの入力を示すのに使われます。<br>
|
||
<li><tt>__STDC__</tt>:<br>
|
||
<tt style="color:maroon">くり色</tt>の等幅フォントは、標準事前定義マクロおよび何らかのマクロを示すのに使われます。<br>
|
||
<li><i>STD</i>:<br>
|
||
<i>Italic</i> フォントは <b>mcpp</b> の system.H というソースファイルで定義されるマクロを表します。このマニュアルではこれらの名前を <b>mcpp</b> の種々の設定を表記するために使います。これらのマクロは <b>mcpp</b> をコンパイルする時に使われるだけで、<b>mcpp</b> の実行プログラムには存在していないことに注意してください。<br>
|
||
</ul>
|
||
<br>
|
||
|
||
<h1><a name="2" href="#toc.2">2. 起動時のオプションと環境設定</a></h1>
|
||
|
||
<h2><a name="2.1" href="#toc.2.1">2.1. <b>mcpp</b> 実行プログラムの２種類のビルドと５つの動作モード</a></h2>
|
||
<p><b>mcpp</b> には、どの処理系（コンパイラ）からも独立して単独で動く <b>compiler-independent-build </b> と、特定の処理系のプリプロセッサに取って代わって動く処理系専用 build (<b>compiler-specific-build) </b> とがあります。前者はプリプロセスだけをするためのもので、その出力を何らかのコンパイラに与えても正しくコンパイルされるとは限りません。後者は特定の処理系でコンパイルとリンクまで行うためのもので、<b>mcpp</b> の出力はそのコンパイラの仕様に合わせてあります。*1, *2</p>
|
||
<p>前者ではオプション等の仕様は <b>mcpp</b> をコンパイルした処理系のいかんにかかわらずほぼ一定で、OS による相違が少しあるだけです。後者では共通の仕様とともに、処理系との互換のための仕様が多くあり、その部分は処理系ごとに異なっています。Compiler-independent 版のオプションは処理系専用版でもほぼ使えますが、処理系のオプションとの衝突を避けるために別のオプションになっているものもあります。<br>
|
||
なお、このドキュメントで「GCC 用」「Visual C 版」等と表記しているのはいずれもそれぞれ GCC 専用 build, Visual C 専用 build の意味です。</p>
|
||
<p>Compiler-independent 版でも処理系専用版でも、<b>mcpp</b> にはいくつかの動作モードがあり、それぞれ異なるプリプロセス仕様で動作します。モードには次の５つあります。</p>
|
||
<ul>
|
||
<li><i>STD</i><br>
|
||
Standard C (C90, C99, C++98) のプリプロセス仕様です。これがデフォルトのモードです。<br>
|
||
<li><i>COMPAT</i><br>
|
||
std モードの変種で、再帰的マクロを規格よりもさらに展開します。<br>
|
||
<li><i>POSTSTD</i><br>
|
||
kmatsui が勝手に作ったプリプロセス仕様で、Standard C の首尾一貫しない規定を整理して単純化したものです。<br>
|
||
<li><i>KR</i><br>
|
||
C90 以前の K&R 1st. のプリプロセス仕様です。<br>
|
||
<li><i>OLDPREP</i><br>
|
||
いわゆる "Reiser" model cpp の動作仕様です。<br>
|
||
</ul>
|
||
<p>これらのモードを指定するオプションは次の通りです。
|
||
モードを何も指定しないと -@std を指定したことになります。</p>
|
||
<ul>
|
||
<li><samp>-@std</samp><br>
|
||
<i>STD</i> モード<br>
|
||
<li><samp>-@compat</samp><br>
|
||
<i>COMPAT</i> モード<br>
|
||
<li><samp>-@post, -@poststd</samp><br>
|
||
<i>POSTSTD</i> モード<br>
|
||
<li><samp>-@kr</samp><br>
|
||
<i>KR</i> モード<br>
|
||
<li><samp>-@old, -@oldprep</samp><br>
|
||
<i>OLDPREP</i> モード<br>
|
||
</ul>
|
||
<p><i>STD</i>, <i>COMPAT</i>, <i>POSTSTD</i> を合わせて Standard モード、<i>KR</i> と <i>OLDPREP</i> を合わせて pre-Standard モードと呼ぶことにします。また、<i>COMPAT</i> は <i>STD</i> とほとんど同じなので、特に断らない限り <i>STD</i> には <i>COMPAT</i> も含め、必要な場合だけ <i>COMPAT</i> に言及します。*3</p>
|
||
<p>Standard と pre-Standard のモードとでは、マクロ展開方法の違いが多くあります。C90 と pre-C90 との違いだと思って間違いありません。最も大きな違いは、関数様マクロ（引数付きマクロ）の展開で、引数にマクロが含まれている場合、Standard モード では引数を先に完全に展開してから元マクロの置換リスト中のパラメータと置き換えるのに対して、pre-Standard では展開せずにパラメータと置換し、再スキャン時に展開することです。<br>
|
||
また、Standard モード では直接にも間接にもマクロの再帰的展開は原則としてしません。pre-Standard では再帰的なマクロ定義があると、展開時に無限再帰を引き起こしてエラーとなります。</p>
|
||
<p>行末にある \ の扱いもモードによって異なり、Standard モード では trigraph 処理の後、tokenization の前に <backslash><newline> の sequence を削除しますが、pre-Standard モード では文字列リテラルの中にある場合と #define 行にある場合に限ってこれを削除します。</p>
|
||
<p>いわゆる tokenization（トークン分割、トークンの切り出し）もモードによって微妙に違います。<br>
|
||
Standard モード では「token base での動作」という建前に忠実に tokenization を行います。具体的には、Standard モード では、マクロを展開するとその前後に space を挿入して、前後の token との意図しない連結が発生するのを防ぎます。pre-Standard モード は伝統的・便宜的・暗黙的な tokenization と、「character base でのテキスト置換」によるマクロ展開方法の痕跡を残しています。これらの点については、<a href="cpp-test.html#2"> cpp-test.html#2</a> をご覧ください。<br>
|
||
Standard モード では preprocessing number という数値トークンを規定通りに扱います。pre-Standard では、数値トークンはＣの整数定数トークンおよび浮動小数点数トークンと同じです。整数定数での接尾子 'U', 'u', 'LL', 'll'、浮動少数点定数での接尾子 'F', 'f', 'L', 'l' はトークンの一部として認識しません。<br>
|
||
ワイド文字の文字列リテラルと文字定数は Standard モード でしか単一のトークンとして認識されません。</p>
|
||
<p>Digraph, #error, #pragma, _Pragma() operator は Standard モード でないと使えません。-S <n> オプション（strict-ansi モード）と -+ オプション（C++ プリプロセッサとして動作する）も Standard モード でしか使えません。事前定義マクロ <tt>__STDC__</tt>, <tt>__STDC_VERSION__</tt> は Standard モード の時に定義され、pre-Standard の時は定義されません。<br>
|
||
#if defined, #elif は pre-Standard では使えません。#include, #line の引数にマクロを使うことは pre-Standard ではできません。事前定義マクロ <tt>__FILE__</tt>, <tt>__LINE__</tt>, <tt>__DATE__</tt>, <tt>__TIME__</tt> は pre-Standard の時は定義されません。<br>
|
||
他方で、#assert, #asm (#endasm), #put_defines, #debug は pre-Standard モードでしか使えません。<br>
|
||
#if 式は Standard モード では long long / unsigned long long で評価しますが、pre-Standard モード では (signed) long だけで評価します。#if 式で sizeof (type) が使えるのは pre-Standard だけです。</p>
|
||
<p>Trigraph と UCN (universal-character-name) は、<i>STD</i> モードでしか使えません。</p>
|
||
<p>診断メッセージの出方もモードによって少し違っています。</p>
|
||
<p>以上に述べたこと以外で K&R 1st. に Standard C と異なる明確な規定のないことがらについては、pre-Standard モード では C90 の規定に従います。</p>
|
||
<p><i>OLDPREP</i> モードの <i>KR</i> モードとの違い、および <i>POSTSTD</i>, <i>COMPAT</i> 各モードの <i>STD</i> モードとの違いは次のようなものです。</p>
|
||
<ul>
|
||
<li><i>OLDPREP</i><br>
|
||
次のような仕様の古い "Reiser model cpp" の動作をする（old preprocessor の意）。<br>
|
||
<br>
|
||
<ol>
|
||
<li>コメントを１個の space でなく０個の space に変換する。この変換は原則として最後の出力時に行わる。ただし、マクロ定義では定義の直後に行われる。<br>
|
||
<li>マクロ定義の置換リスト中に文字列リテラルまたは文字定数があり、その中にどれかのパラメータ名と一致する部分がある場合は、そのマクロの呼び出しの際にこの部分は、パラメータに対応する引数で置き換えられる。一致する部分というのは、両端の " または ' をはずした中身をトークン列として見た場合に一致するトークンのことである。<br>
|
||
<li>#else, #endif の行に何が書いてあってもエラーにせず無視する（対応する #if MACRO, #ifdef MACRO の MACRO を書いたりする）。<br>
|
||
<li>リテラルを閉じる " や ' がない場合は、行末で閉じられているとみなす（unterminated string literal, unterminated character constant のエラーが発生しない）。<br>
|
||
<li># 123 という行を #line 123 と同じものとして扱う。<br>
|
||
<br>
|
||
</ol>
|
||
<li><i>COMPAT</i><br>
|
||
再帰的マクロを規格よりもさらに展開する。
|
||
すなわち、再帰的マクロの展開に際して、同名マクロの再置換を禁止する範囲を規格よりも狭くとる。<br>
|
||
再帰的マクロの展開の規定については <a href="cpp-test.html#3.4.26"> cpp-test.html#3.4.26</a> を参照のこと。再帰的マクロの具体例は test-t/recurs.t を参照のこと。*4<br>
|
||
<br>
|
||
<li><i>POSTSTD</i><br>
|
||
これは規格に次のような変更を加えたものである。<br>
|
||
<br>
|
||
<ol>
|
||
<li>Trigraphs は認識しない。Digraph は translation phase 1 で、すなわちプリプロセスの最初に変換してしまう。Token としては扱わない。<br>
|
||
<li>Tokenization を完全な token-base の原則にしたがって単純化している。ソース中の preprocessing token の間に token separator としての white space がない場合は、そこに自動的に a space を挿入する（ただし、マクロ定義中のマクロ名と次の '(' の間には挿入しない）。したがって、# 演算子による文字列化でもすべての preprocessing token の間には a space が入った上で文字列化されることになる。また、マクロの再定義に際しては、token separator の有無は問題にならない。<br>
|
||
<li>関数様マクロの再定義に際しては、パラメータ名の違いは問題にしない。<br>
|
||
<li>#if 式中に文字定数は使えない（エラーにする）。<br>
|
||
<li>関数様マクロの展開に関する「関数様」でない不規則な規定をカットしている。
|
||
すなわち、再スキャンはそのマクロの置換リストだけを対象とし、その後ろの sequence は取り込まない。<br>
|
||
<li>#include <stdio.h> という形式の header name は通常は通すが、ウォーニングを出す（class 2 のウォーニングオプションで）。マクロで <stdio.h> の形の header name を使うと、特殊な場合にはエラーとなることがある。#include "stdio.h" の形式を推奨する。<br>
|
||
<li>マクロ定義ではマクロ名と置換リストとの間に space が必要という規定が C99 で追加されたが、この規定には従わない（tokenization の際に自動的に a space が挿入されるので）。<br>
|
||
<li>UCN (universal-character-name) は認識しない。また、identifier 中の multi-byte character も認識しない。<br>
|
||
<li>C++ では１１種の identifier 様 operator は operator としては扱わない。<br>
|
||
</ol>
|
||
</ul>
|
||
<p>なお、このほか <b>lang-asm</b> モードというものもあります。
|
||
これはアセンブラソースに C のコメント、ディレクティブ、マクロが挿入された変則的なソースを処理するモードです。
|
||
<i>POST_STD</i> はこのモードになることはできませんが、それ以外のモードは一定のオプションを指定することでこのモードになります。
|
||
その仕様については <a href="#2.5">2.5</a> を見てください。</p>
|
||
<p>こういうことで <b>mcpp</b> の実行プログラムにはいくつもの仕様があるので、マニュアルを注意して読んでください。この章ではまず <b>mcpp</b> の共通のオプションを説明し、次に動作モードによって異なるオプションを述べ、次に特定の処理系専用版を除いて共通のオプションを述べ、そのあとで処理系専用版の処理系ごとに異なるオプションを記載します。</p>
|
||
<p>注:</p>
|
||
<p>*1 このほか subroutine-build というものもある。何らかの他のメインプログラムから <b>mcpp</b> がサブルーチンとして呼び出されるものである。しかし、その仕様は <b>mcpp</b> をコンパイルした時の設定によって compiler-specific-build または compiler-independent-build のどちらかと同じになるので、このマニュアルでは特にとりあげない。
|
||
Subroutine-build については <a href="mcpp-porting.html#3.12">mcpp-porting.html#3.12</a> を参照のこと。</p>
|
||
<p>*2 SourceForge のサイトで提供するバイナリ・パッケージはすべて compiler-independent-build である。</p>
|
||
<p>*3 V.2.5 までは Standard モードと pre-Standard モードとで実行プログラムが別になっていたが、V.2.6 から１つに統合された。</p>
|
||
<p>*4 これは GCC, Visual C++ 等の主要な処理系との互換性のためのオプションである。'<i>COMPAT</i>' は "compatible" の意味である。</p>
|
||
<br>
|
||
|
||
<h2><a name="2.2" href="#toc.2.2">2.2. 起動時のオプションの指定法</a></h2>
|
||
<p>以下の記載では、<arg> という記法は arg がユーザの入力すべき任意の引数であることを示し、[arg] は arg が省略可能な引数であることを示します。どちらにしても <, >, [, ] の文字そのものは入力してはいけません。</p>
|
||
<p><b>mcpp</b> を起動する書式は次の形です。ただし、mcpp という名前は <b>mcpp</b> のインストール時の指定によっては別の名前になります。</p>
|
||
<pre>
|
||
mcpp [-<opts> [-<opts>]] [in_file] [out_file] [-<opts> [-<opts>]]
|
||
</pre>
|
||
<p>out_file（出力パス）が省略された時は（-o オプションが指定されない限り）標準出力に出力します。in_file（入力パス）も省略された時は標準入力から入力します。診断メッセージは（-Q オプションが指定されない限り）標準エラー出力に出力します。<br>
|
||
これらのどれかのファイルがオープンできない時は、エラーメッセージを出して終了します。</p>
|
||
<p>引数を必要とするオプションに引数がない場合はエラーとなります（-M オプションだけは別）。<br>
|
||
引数を必要とするオプションでは -I<arg>, -I <arg> のどちらも有効です（オプション文字と引数の間に space はあってもなくても良い）。<br>
|
||
引数のないオプションは -Qi, -Q -i のどちらも有効です（１つの '-' の後につなげても別々に '-' を付けても良い。ただし、-M はつなげてはいけない）。<br>
|
||
同一のオプションが複数回指定された場合、-D, -U, -I, -W オプションはそれぞれが有効です。-S, -V, -+ は２回目以降は無視されます。-2, -3 はそのたびに仕様が反転します。その他のオプションは最後に指定されたものが有効です。</p>
|
||
<p>大文字と小文字は区別されます。<br>
|
||
いわゆるスイッチキャラクタは Windows でも - であり、/ ではありません。<br>
|
||
不正なオプションを指定すると usage 文が表示されるので、mcpp -? 等とすることで、使えるオプションを確かめることができます。Usage 文のほかにもいくつかのエラーメッセージがありますが、その内容はいずれも自明のものであるので、説明は省略します。</p>
|
||
<br>
|
||
|
||
<h2><a name="2.3" href="#toc.2.3">2.3. 共通のオプション</a></h2>
|
||
<p><b>mcpp</b> の動作モードや処理系によらない共通のオプションは次の通りです。</p>
|
||
<ul>
|
||
<li><samp>-C</samp><br>
|
||
ソース中のコメントも出力する。デバッグ時に有用なオプションである。ただし、コメントはソースの論理行の先頭に移して出力する。コメントの処理はマクロ展開やディレクティブの処理の前に行われるものであり、コメントはマクロ呼び出しの途中にあるかもしれないからである。<br>
|
||
<br>
|
||
<li><samp>-D <macro>[=[<value>]]</samp><br>
|
||
<li><samp>-D <macro(a,b)>[=[<value>]]</samp><br>
|
||
マクロ macro を定義する。事前定義されているマクロでも <tt>__STDC__, __STDC_VERSION__, __FILE__, __LINE__, __DATE__, __TIME__, __cplusplus</tt> 以外であれば、このオプションで定義が変更できる（C99 の <tt>__STDC_HOSTED__</tt> は GCC V.3 のように -D オプションで定義する処理系もあるので、例外的に許可する）。=<value> が指定されていれば value に定義し、省略されていれば 1 に定義する（bcc32 では省略時には０個のトークンに定義されるので、それとは違うことに注意）。= の前には空白を入れてはいけない。= の後に空白があればそのマクロは０個のトークンに定義される。<br>
|
||
このオプションでは、引数つきマクロも定義できる。<br>
|
||
このオプションは何回でも指定できる。
|
||
<br>
|
||
<br>
|
||
<li><samp>-e <encoding></samp><br>
|
||
Multi-byte character の encoding を <encoding> に変更する。
|
||
<encoding> については <a href="#2.8"> 2.8</a> を参照のこと。
|
||
<br>
|
||
<br>
|
||
<li><samp>-I <directory></samp><br>
|
||
Include directory のサーチパスの第一位に directory を指定する（サーチパスについては <a href="#4.2"> 4.2</a> を参照）。directory 名に space が含まれる場合は、directory 名全体を " と " で囲むこと。<br>
|
||
<br>
|
||
<li><samp>-I 1, -I 2, -I 3</samp><br>
|
||
#include
|
||
"header" の形式の（<header> の形式ではない）ディレクティブで最初にサーチされるディレクトリの基準を指定する。-I1 ではカレントディレクトリ、-I2 ではソースファイル（インクルード元）のあるディレクトリ、-I3 ではその双方をサーチする（詳細は <a href="#4.2"> 4.2</a> を参照）。<br>
|
||
<br>
|
||
<li><samp>-j</samp><br>
|
||
診断メッセージの出力ではソース行等の付加情報は出力せず、１行の診断メッセージだけ出力する（デフォルトでは１行の診断メッセージに続いて、そのソース行が表示される。ソースファイルが include されたものである場合は、include 元の行も順次表示される。マクロに関する診断メッセージでは、展開前のマクロも順次表示される）。<br>
|
||
GCC の testsuite で私の検証セットを使う時は、このオプションを指定して、GCC と同じ診断メッセージ形式にする必要がある。<br>
|
||
<br>
|
||
</ul>
|
||
<p>-M* オプションは makefile 用の依存関係行を出力するものです。複数のソースファイルがある場合、すべてのソースについてこれらの -M* オプションを付けて実行して、その出力をマージすると、makefile で必要な依存関係記述行がそろいます。これらのオプションは GCC のものに合わせていますが、少し違いがあります。*1</p>
|
||
<ul>
|
||
<li><samp>-M</samp><br>
|
||
ソースファイルの依存関係を記述する行を出力する。出力先はコマンドラインで指定された出力ファイル、それが指定されていなければ標準出力である。行が長ければ折りたたむ。通常のプリプロセス結果は出力しない。<br>
|
||
<br>
|
||
<li><samp>-MM</samp><br>
|
||
-M とほぼ同じであるが、次のヘッダは書き出さない。<br>
|
||
<ol>
|
||
<li>#include <stdio.h> の形式で include されるもの。<br>
|
||
<li>#include "/include/stdio.h" 等と絶対パスで指定されているもの。<br>
|
||
<li>#include "stdio.h" の形式であるが、カレントディレクトリ（処理系や -I <n> オプションによってはソースのあるディレクトリ）で発見されず、システム等の include ディレクトリで発見されたもの（-I <directory> オプションや環境変数等で指定されたディレクトリも含む）。<br>
|
||
</ol>
|
||
ただし、GCC-specific-build では GCC と同様に、書き出さないのはシステムヘッダだけである。<br><br>
|
||
<li><samp>-MD [FILE]</samp><br>
|
||
-M とほぼ同じであるが、通常のプリプロセス結果もコマンドラインで指定されたファイルまたは標準出力に出力されることが違っている。また、依存関係行の出力先は、 FILE が指定された時はそのファイルとなり、指定されていない時はソースファイル名の .c を .d に変えたファイルとなる。<br>
|
||
<br>
|
||
<li><samp>-MMD [FILE]</samp><br>
|
||
-MD とほぼ同じであるが、-MM と同様にシステムヘッダとみなされるものは書き出さないことが違っている。依存関係行の出力先は -MD [FILE] と同じ。<br>
|
||
<br>
|
||
<li><samp>-MF FILE</samp><br>
|
||
出力先を FILE にする。-MD FILE, -MMD FILE に優先する。<br>
|
||
<br>
|
||
<li><samp>-MP</samp><br>
|
||
"Phony target" も出力する。Phony target というのは、インクルードされるファイル１つ１つについて、それ自体を依存先を持たないターゲットとして、次のように記述するものである。<br>
|
||
<pre>
|
||
test.o: test.c test.h
|
||
test.h:
|
||
</pre>
|
||
<li><samp>-MT TARGET</samp><br>
|
||
ターゲットの名前を通常の foo.o ではなく TARGET にする。-MT '$(objpfx)foo.o' というオプションでは次のような行が出力される。<br>
|
||
<pre>
|
||
$(objpfx)foo.o: foo.c
|
||
</pre>
|
||
<li><samp>-MQ TARGET</samp><br>
|
||
-MT と同様であるが、make にとって特別な意味を持つ文字は次のように quote する。<br>
|
||
<pre>
|
||
$$(objpfx)foo.o: foo.c
|
||
</pre>
|
||
<li><samp>-N</samp><br>
|
||
'_' で始まるものも含めてすべての事前定義マクロを無効にする。ただし、規格で要求されている事前定義マクロおよび __MCPP は除く。規格で要求されている事前定義マクロとは、<tt>__FILE__, __LINE__, __DATE__, __TIME__, __STDC__, __STDC_VERSION__</tt>, C99 の <tt>__STDC_HOSTED__</tt> および C++ の <tt>__cplusplus</tt> である。（<tt>__MCPP</tt> を undefine したい場合は -U オプションを使うこと）。<br>
|
||
<br>
|
||
<li><samp>-o <file></samp><br>
|
||
プリプロセス後のソースを file に出力する。省略時は第二引数が出力パスとなるので、無くてもよいオプションであるが、コンパイラドライバによってはこのオプションを使うものがある。<br>
|
||
<br>
|
||
<li><samp>-P</samp><br>
|
||
コンパイラ本体に行番号情報を伝える出力を省略する。Ｃのプリプロセッサ以外の用途に流用する場合に使うオプションである。<br>
|
||
<br>
|
||
<li><samp>-Q</samp><br>
|
||
診断メッセージを（カレントディレクトリの）mcpp.err という名前のファイルに出力する（mcpp.err は後ろにアペンドされてゆくので、時々削除すること）。<br>
|
||
<br>
|
||
<li><samp>-U <macro></samp><br>
|
||
事前定義されているマクロ macro を取り消す（<tt>__FILE__, __LINE__, __DATE__, __TIME__, __STDC__, __STDC_VERSION__</tt>, C99 モードでの <tt>__STDC_HOSTED__</tt> および -+ オプションで起動した時の <tt>__cplusplus</tt> は取り消せない）。<br>
|
||
<br>
|
||
<li><samp>-v</samp><br>
|
||
<b>mcpp</b> のバージョンおよびインクルードディレクトリのサーチ順を標準エラー出力に出力する。<br>
|
||
ただし、<a href="#2.4">2.4</a> で述べる -K オプションが指定された時、または <a href="#3.5.8">3.5.8</a> で述べる #pragma MCPP macro_call が指定された時は、このオプションはその意味を変える。<br>
|
||
<br>
|
||
<li><samp>-W <level></samp><br>
|
||
Warning を出力するレベルを level に指定する。
|
||
level は 0 または 1, 2, 4, 8, 16 のうちの任意の値の OR をとったものである。
|
||
1, 2, 4, 8, 16 はそれぞれ warning の class を意味する。
|
||
例えば -W 5 では class 1, 4 の warning が出力される。
|
||
0 の場合は warning は出力しない。
|
||
このオプションが複数回指定されると、すべての指定の OR がとられる。
|
||
例えば -W 1 -W 2 -W 4 は -W 7 と同じである。
|
||
-W 7 の代わりに -W "1|2|4" とすることもできる（| がパイプと解釈されないように " と " で囲う必要がある）。
|
||
-W "3|4" 等としてもかまわない。
|
||
ただし、-W 0 が指定された場合は、他の -W オプションはすべてキャンセルされる。
|
||
このオプションを指定しない時は -W 1 を指定したのと同じである（warning の内容は <a href="#5.5"> 5.5</a> - <a href="#5.9"> 5.9</a> を参照）。<br>
|
||
<br>
|
||
<li><samp>-z</samp><br>
|
||
#include で取り込まれたファイルのプリプロセス結果は出力しない。
|
||
しかし、マクロは定義される。
|
||
その代わりに #include 行そのものを出力する。
|
||
Include されたファイルの中の #include 行は出力しない。
|
||
プリプロセスのデバッグ時に使うオプションである。<br>
|
||
</ul>
|
||
<p>注:</p>
|
||
<p>*1 GCC と違うのは次の点である。</p>
|
||
<ol>
|
||
<li>-MG オプションはない。オプション指定の仕方が複雑すぎるからである（したがって、どういう仕様かの説明は略）。
|
||
しかし、-M オプションでも、インクルードファイルが見つからない場合はエラーにはなるが、依存関係行は出力されるので、それで代用できる。<br>
|
||
<li>GCC-specific-build は GCC に合わせてあるが、それ以外では、-MM, -MMD オプションで除外されるヘッダの範囲が広い。<br>
|
||
</ol>
|
||
<br>
|
||
|
||
<h2><a name="2.4" href="#toc.2.4">2.4. <b>mcpp</b> のモードによるオプション</a></h2>
|
||
<p><b>mcpp</b> にはいくつかの動作モードがあります。その仕様は <a href="#2.1"> 2.1</a> を参照してください。
|
||
<br>
|
||
このマニュアルでは各種のモードの仕様が並べて記載されているので、少々見にくくなっていますが、がまんしてください。また、以下の説明で出てくる <i>DIGRAPHS_INIT</i>, <i>TRUE</i>, <i>FALSE</i>, etc. の大文字名（__ で始まらないもの）で <i>italic</i> で表示されているものはすべて system.H で定義されるマクロです。これらのマクロはあくまでも <b>mcpp</b> 自身をコンパイルする時に使われるだけで、できあがった <b>mcpp</b> 実行プログラムにはこれらのマクロは残ってはいません。勘違いしないようにしてください。</p>
|
||
<p>Standard モードでは次のオプションが使えます。</p>
|
||
<ul>
|
||
<li><samp>-+</samp><br>
|
||
C++ のプリプロセッサとして動作する。マクロ <tt>__cplusplus</tt> を事前定義し（その値は system.H で定義されている。デフォルトは 1）、// から論理行の行末までをコメントと解釈し、<samp>::, .*, ->*</samp> をそれぞれ単一のトークンとして認識する。#if 式中では true, false というトークンはそれぞれ 1, 0 と評価する。<tt>__STDC__</tt>, <tt>__STDC_VERSION__</tt> が定義されていれば、それを削除する（ただし、GCC 専用版では GCC との互換性のために <tt>__STDC__</tt> は削除しない）。_ で始まらない事前定義マクロも削除する。ただし、extended characters の UCN への変換はしない。*1, *2<br>
|
||
<br>
|
||
<li><samp>-2</samp><br>
|
||
Digraphs 処理の初期設定を反転する。<i>DIGRAPHS_INIT</i> == <i>FALSE</i> の場合はこれで digraph を認識するようになり、逆の場合は認識しなくなる。<br>
|
||
<br>
|
||
<li><samp>-h <n></samp><br>
|
||
マクロ <tt>__STDC_HOSTED__</tt> の値を <n> に定義する。<br>
|
||
<li><samp>-S <n></samp><br>
|
||
C では <tt>__STDC__</tt> の値を <n> に変更する。C++ では無視される。<n> は [0,9] の範囲の数値でなければならない。<n> が 1 以上であれば、_ で始まらない事前定義マクロ（<tt>unix, linux</tt> 等）を無効にする。<br>
|
||
S は <tt>__STDC__</tt> の意味である。このオプションを指定しないと、<tt>__STDC__</tt> はデフォルトの値となる（通常は 1）。<br>
|
||
GCC 版では -pedantic, -pedantic-errors, -lang-c89 でも -S1 を指定したと同じことになるので、その次の -S は無視される。
|
||
また、これらのオプションでは <tt>unix, linux, i386</tt> 等、規格違反の事前定義マクロは無効にならない。
|
||
GCC との互換性のためである。
|
||
これらの事前定義マクロは -ansi または -std=iso* オプションで初めて無効になる。<br>
|
||
<br>
|
||
<li><samp>-V <value></samp><br>
|
||
C では <tt>__STDC_VERSION__</tt>、C++ では <tt>__cplusplus</tt> という事前定義マクロの値を指定された値 <value> に変更する。この場合の <value> は long の値となる（C95 ではこの値は 199409L、C99 では 199901L、C++ Standard では 199711L である）。<tt>__STDC__</tt> が 0 に定義されていると <tt>__STDC_VERSION__</tt> は必ず 0L となり、-V は無効である。<br>
|
||
C では、このオプションを指定しないと、<tt>__STDC_VERSION__</tt> は system.H の <i>STDC_VERSION</i> の値となる（GCC V.2.7 - V.2.9 では 199409L、それ以外では 0L）。-V199901L として <tt>__STDC_VERSION__</tt> >= 199901L になった場合は次のような C99 の仕様となる（<a href="#3.7"> 3.7</a> 参照）。<br>
|
||
<br>
|
||
<ol>
|
||
<li>// から行末までをコメントとして扱う。
|
||
*3<br>
|
||
<li>Preprocessing-number の中に e+, E+, e-, E- と同様に p+, P+, p-, P- という sequence も認める。これは浮動小数点数のビットパターンを 0x1.FFFFFEp+128 というふうに、１６進で表記するためのものである。<br>
|
||
<li>_Pragma( "foo bar") と書くと #pragma foo bar と書いたのと同じ効果を持つ _Pragma operator が有効になる。<br>
|
||
<li><i>EXPAND_PRAGMA</i> というマクロを <i>TRUE</i> に定義してコンパイルされた <b>mcpp</b> では、#pragma 行の引数は、STDC または <b>mcpp</b> で始まるのでない限りマクロ展開の対象となる（デフォルトでは Visual C, Borland C 版以外では <i>EXPAND_PRAGMA</i> == <i>FALSE</i> であり、マクロ展開しない）。<br>
|
||
<li>識別子・文字定数・文字列リテラル・pp-number の中にある UCN (universal-character-name) の sequence を通す（これは <i>STD</i> モードに限る）。<br>
|
||
<br>
|
||
</ol>
|
||
なお、可変引数マクロは C99 の仕様であるが、C90 および C++ でも使えるようにしてある。*4<br>
|
||
C++ でも -V199901L として <tt>__cplusplus</tt> >= 199901L にすると、C99 互換モードとなり、上記 2,3,4 の機能拡張を行う（1 は無条件で有効。5 はほぼ同様）。これは <b>mcpp</b> 独自の拡張であり、C++ Standard には違反する。<br>
|
||
なお、これらのマクロ <tt>__STDC__</tt>, <tt>__STDC_VERSION__</tt>, <tt>__cplusplus</tt> の指定に -D オプションは使えない。一般のユーザ定義マクロと区別するためである。<br>
|
||
</ul>
|
||
<p><i>STD</i> モードでは次のオプションが使えます。</p>
|
||
<ul>
|
||
<li><samp>-3</samp><br>
|
||
Trigraph 処理の初期設定を反転する。
|
||
<i>TRIGRAPHS_INIT</i> == <i>FALSE</i> の場合はこれで trigraph を認識するようになり、逆の場合は認識しなくなる。<br>
|
||
<li><samp>-K</samp><br>
|
||
マクロに関する情報をコメントに書き込んで出力する「マクロ注釈モード」(macro notification mode) を指定する。
|
||
このモードでは、プリプロセス後の出力から元のソース上のマクロの位置を知ることができる。
|
||
このモードは C/C++ の refactoring tool のために実装されたものである。
|
||
C/C++ にはプリプロセスというフェーズのあることが refactoring tool にとって困難な問題を引き起こすが、このモードを使えばプリプロセス後の出力からソースを再構成することができる。
|
||
さらに、出力をそのまま再プリプロセスしてコンパイルすることができる。*5<br>
|
||
このモードは次の pragma で指定することもできる。
|
||
<pre>
|
||
#pragma MCPP debug macro_call
|
||
</pre>
|
||
-K オプションはこの pragma をソースの冒頭に書いたのとほぼ同じ効果を持つ。
|
||
ただし、pragma では事前定義マクロは出力されない。
|
||
Macro notification の仕様については <a href="#3.5.8">3.5.8. #pragma MCPP debug macro_call</a> を参照のこと。<br>
|
||
このモードでは次の -k オプションが自動的に指定される。
|
||
このモードで同時に -v オプションが指定された時は -v オプションはその意味を変え、macro notification の内容がより詳細になる。
|
||
また、-a (-x assembler-with-cpp) または -C オプションが指定された時は、-K オプションは自動的に無効になる。*6<br>
|
||
</p>
|
||
<li><samp>-k</samp><br>
|
||
ソース中の horizontal white spaces (space, tab) を圧縮せずにそのまま出力する。
|
||
コメントは同じ長さの spaces に変換する。
|
||
ソースとプリプロセス後の出力との column 位置の対応を維持するためのオプションである。
|
||
マクロがあると位置がずれるが、-K オプションを使うとそれも元の位置を知ることができる。*7<br>
|
||
</ul>
|
||
<p>注:</p>
|
||
<p>*1 C++ で <tt>__STDC__</tt> が定義されているのはトラブルの元であり、良い仕様ではない。GCC のドキュメントによると、ヘッダファイルの多くが <tt>__STDC__</tt> が定義されていることを期待しているので、C++ でもこれを定義しておく必要がある、とのことである。しかし、これはヘッダファイルの書き方が悪いと言わざるをえない。C90, C99, C++ に共通の部分には、<samp>#if __STDC__ || __cplusplus</samp> と書くべきなのである。</p>
|
||
<p>*2 C++ Standard では C99 と違って、UCN は大々的な扱いを受けており、中途半端な実装はできない。C 1997/11 draft でもそうであった。しかし、Unicode をそこまで導入することには、実装の負担が大きすぎること等の問題があって疑問だからである。</p>
|
||
<p>*3 // は C90（Standard モードの場合）でもコメントとして扱うが、ウォーニングを出す。</p>
|
||
<p>*4 これは GCC との互換性のためである。</p>
|
||
<p>*5 GCC-specific-build の <b>mcpp</b> をインストールすると、<b>mcpp</b> によるプリプロセス出力が cc1 (cc1plus) に -fpreprocessed というオプションを付けて渡されるようになる。
|
||
このオプションは入力がプリプロセスずみであることを cc1 に伝えるものであるが、それでもコメントは処理される。
|
||
したがって、-K オプションの結果を cc1 に -fpreprocessed オプションを付けて渡して差し支えない。
|
||
また、gcc (g++) コマンドに -save-temps というオプションを付けると、プリプロセス結果の *.i (*.ii) ファイルが残されるので、それを refactoring tool で処理することができる。</p>
|
||
<p>*6 -x assembler-with-cpp オプションでは C/C++ のソースではない GCC 用の *.S ファイルがソースファイルとして使われるが、この *.S ファイルのプリプロセスでは、-K オプションを使ってコメントを挿入するとカラム位置がずれるため、アセンブルできなくなるからである。
|
||
また、-C オプションによるコメントも -K オプションで挿入されたコメントと紛らわしいことがあるので、同時には使えない。</p>
|
||
<p>*7 このオプションを使っても、特殊な場合には正確な対応が維持されないことがある。
|
||
<backslash><newline> による行連結と行をまたぐコメントによる行連結が連続する場合や、コメントが 256 行以上続く場合などである。
|
||
なお、このオプションを指定してもしなくても、'\v', '\f' は space に変換される。</p>
|
||
<br>
|
||
|
||
<h2><a name="2.5" href="#toc.2.5">2.5. 特定の処理系以外の処理系に共通のオプション</a></h2>
|
||
<p>UNIX 系のシステムでは次の２つのオプションが使えます。
|
||
処理系独立版・GCC 専用版に共通です。
|
||
ただし、GCC 専用版では GCC が対応していないとエラーになります。</p>
|
||
<ul>
|
||
<li><samp>-m32</samp><br>
|
||
事前定義マクロを 32 ビット用にする。
|
||
CPU が x86_64 または ppc64 の場合、デフォルトでは 64 ビット用の事前定義マクロが使われるが、このオプションを指定するとそれぞれ i386, ppc 用のものが使われる。<br>
|
||
<li><samp>-m64</samp><br>
|
||
事前定義マクロを 64 ビット用にする。
|
||
CPU が i386 または ppc の場合、デフォルトでは 32 ビット用の事前定義マクロが使われるが、このオプションを指定するとそれぞれ x86_64, ppc64 用のものが使われる。<br>
|
||
</ul>
|
||
|
||
<p>GCC はオプションが非常に多いので、GCC 専用版ではそれとの衝突を避けるためにいくつかのオプションは他の処理系とは違うものにしています。なお、GCC でコンパイルした <b>mcpp</b> でも compiler-independent 版のオプションは他の処理系でコンパイルしたものと同じです。以下のオプションは GCC 専用版以外に共通のものです。</p>
|
||
<ul>
|
||
<li><samp>-a</samp><br>
|
||
ある種のアセンブラソースに見られる次のような記法をエラーにせずに通す。<br>
|
||
<ol>
|
||
<li>
|
||
<pre>
|
||
#APP
|
||
</pre>
|
||
<p>のように # の次の identifier がＣのディレクティブに合致しない場合、この行をそのまま出力する。</p>
|
||
<li>
|
||
<pre>
|
||
# + any comment.
|
||
</pre>
|
||
<p>といった # の次に identifier, pp-number 以外のものが現れる行は、ウォーニングとともに捨てるがエラーにはしない。</p>
|
||
<li>
|
||
<pre>
|
||
"Jugemjugem
|
||
gokouno
|
||
surikire"
|
||
</pre>
|
||
<p>といった大昔の流儀の行をまたぐ文字列リテラルを<br>
|
||
<samp>"Jugemjugem\ngokouno\nsurikire"</samp><br>
|
||
という行に連結する。</p>
|
||
<li>## 演算子による token の連結で pp-token としては無効な token が生成されても、エラーにしない。<br><br>
|
||
<li>マクロを展開した前後に space を挿入しない。
|
||
その結果、前後の pp-token と暗黙のうちに連結されてもエラーにしない。<br>
|
||
</ol>
|
||
<p>これらは GNU のソースなどに時々見られるものですが、GCC 版ではこのオプションは -x assembler-with-cpp および -lang-asm です。<br>
|
||
ただし、このオプションは <i>POSTSTD</i> モードでは使えません。<br>
|
||
このモードをこのマニュアルでは <b>lang-asm</b> モードと呼びます。<br>
|
||
このモードは <b>mcpp</b> を C/C++ 以外のテキストのマクロ・プロセッサとして使う場合に適しています。xrdb から呼び出す cpp として使う場合などです。</p>
|
||
<li><samp>-I-</samp><br>
|
||
デフォルトの include directory がキャンセルされ、環境変数で指定された directory および他の -I オプションで指定された directory だけが有効となる。ただし、GCC 版ではこのオプションは -I- ではなく -nostdinc である。GCC では -I- オプションはまったく違った意味を持つ（<a href="#2.6"> 2.6</a> 参照）。<br>
|
||
</ul>
|
||
<br>
|
||
|
||
<h2><a name="2.6" href="#toc.2.6">2.6. 処理系ごとのオプション</a></h2>
|
||
<p>特定の処理系でプリプロセッサとして <b>mcpp</b> を使うには、処理系のプリプロセッサのある場所に適当な名前で置いておきます。その時に、処理系付属のプリプロセッサを消してしまうことのないよう、あらかじめ別名のファイルにコピーしておいてください。<br>
|
||
Linux, FreeBSD, CygWIN での設定については <a href="#3.9.5"> 3.9.5</a> を参照してください。
|
||
GCC 3.*, 4.* での設定については <a href="#3.9.7">3.9.7</a>, <a href="#3.9.7.1">3.9.7.1</a> を参照してください。MinGW での設定についても <a href="#3.9.7.1">3.9.7.1</a> を参照してください。
|
||
</p>
|
||
<p>処理系付属のコンパイラドライバからは通常の方法では <b>mcpp</b> に渡す方法のないオプションもあります。<br>
|
||
Gcc では -Wp というオルマイティオプションを使うと、どんなオプションでもプリプロセッサに渡すことができます。例えば、</p>
|
||
<pre>
|
||
gcc -Wp,-W31,-Q23
|
||
</pre>
|
||
<p>とすると、プリプロセッサに -W31 -Q23 というオプションが渡されます。プリプロセッサに渡したいオプションを -Wp, に続けて , で区切って並べます。*1, *2</p>
|
||
<p>他の処理系でも、もしコンパイラドライバのソースがあれば、この種のオルマイティオプションを追加したほうが良いでしょう。例えば、-P<opt> と指定すると P をとった -<opt> がプリプロセッサに渡されるようにしておくと、どんなオプションでも使えるようになるので便利です。</p>
|
||
<p>もう１つの方法は、先に <b>mcpp</b> でプリプロセスして、その出力ファイルをソースファイルとしてコンパイラに渡すように makefile を書くことです。この方法については <a href="#2.9"> 2.9</a>, <a href="#2.10"> 2.10</a> を参照してください。
|
||
</p>
|
||
|
||
<p><b>mcpp</b> の特定の処理系ごとのオプションは以下の通りです。Compiler-independent 版にはもちろんこれらのオプションはありません。</p>
|
||
<p>LCC-Win32 版では次のオプションが使えます。</p>
|
||
<ul>
|
||
<li><samp>-g <n></samp><br>
|
||
マクロ <tt>__LCCDEBUGLEVEL</tt> を <n> に定義する。<br>
|
||
<li><samp>-O</samp><br>
|
||
マクロ <tt>__LCCOPTIMLEVEL</tt> を 1 に定義する。
|
||
<br>
|
||
</ul>
|
||
<p>Visual C 版では次のオプションが使えます。
|
||
</p>
|
||
<ul>
|
||
<li><samp>-arch:SSE, -arch:SSE2</samp><br>
|
||
マクロ <tt>_M_IX86_FP</tt> をそれぞれ 1, 2 に定義する。
|
||
<br>
|
||
<li><samp>-Fl <file></samp><br>
|
||
GCC の -include <file> と同じ。
|
||
<br>
|
||
<li><samp>-G<n></samp><br>
|
||
<n> が 3, 4, 5, 6, B であれば、マクロ <tt>_M_IX86</tt> をそれぞれ 300, 400, 500, 600, 600 に定義する。<br>
|
||
<li><samp>-GR</samp><br>
|
||
マクロ <tt>_CPPRTTI</tt> を 1 に定義する。
|
||
<br>
|
||
<li><samp>-GX</samp><br>
|
||
マクロ <tt>_CPPUNWIND</tt> を 1 に定義する。
|
||
<br>
|
||
<li><samp>-GZ</samp><br>
|
||
マクロ <tt>__MSVC_RUNTIME_CHECKS</tt> を 1 に定義する。
|
||
<br>
|
||
<li><samp>-J</samp><br>
|
||
マクロ <tt>_CHAR_UNSIGNED</tt> を 1 に定義する。
|
||
<br>
|
||
<li><samp>-RTC*</samp><br>
|
||
-RTC1, -RTCc, -RTCs, -RTCu 等のオプションが指定されると、マクロ <tt>__MSVC_RUNTIME_CHECKS</tt> を 1 に定義する。<br>
|
||
<li><samp>-Tc, -TC</samp><br>
|
||
C のソースであることを指示する。
|
||
指定しなくても同じ。<br>
|
||
<li><samp>-Tp, -TP</samp><br>
|
||
-+ オプションと同じ。
|
||
<br>
|
||
<li><samp>-u</samp><br>
|
||
-N オプションと同じ。
|
||
<br>
|
||
<li><samp>-Wall</samp><br>
|
||
-W17 (-W1 -W16) と同じ。
|
||
<br>
|
||
<li><samp>-WL</samp><br>
|
||
-j オプションと同じ。
|
||
<br>
|
||
<li><samp>-w</samp><br>
|
||
-W0 オプションと同じ。
|
||
<br>
|
||
<li><samp>-X</samp><br>
|
||
-I- オプションと同じ。
|
||
<br>
|
||
<li><samp>-Za</samp><br>
|
||
マクロ <tt>_MSC_EXTENSIONS</tt> を未定義にし、identifier 中に '$' を使えないようにする。
|
||
<li><samp>-Zc:wchar_t</samp><br>
|
||
マクロ <tt>_NATIVE_WCHAR_T_DEFINED</tt>, <tt>_WCHAR_T_DEFINED</tt> をそれぞれ
|
||
1 に定義する。<br>
|
||
<li><samp>-Zl</samp><br>
|
||
マクロ <tt>_VC_NODEFAULTLIB</tt> を 1 に定義する。
|
||
<br>
|
||
</ul>
|
||
|
||
<p>Mac OS X 上の <b>mcpp</b> では GCC-specific-build でも compiler-independent-build でも、次のオプションが使えます。</p>
|
||
<ul>
|
||
<li><samp>-F <framework></samp><br>
|
||
<framework> ディレクトリを標準の framework ディレクトリに優先してサーチする。
|
||
標準の framework ディレクトリはデフォルトでは /System/Library/Frameworks, /Library/Frameworks である。
|
||
</ul>
|
||
<p>Mac OS X 上の GCC-specific-build では次のオプションが使えます。</p>
|
||
<ul>
|
||
<li><samp>-arch <arch></samp><br>
|
||
ターゲットマシンのアーキテクチャをデフォルトのものから <arch> に変更する。
|
||
それによって、事前定義マクロのいくつかが変わる。
|
||
<arch> として有効なのは x86 の実行プログラムでは i386, x86_64、ppc の実行プログラムでは ppc, ppc64 のどれかである
|
||
（gcc コマンドには４つのどれでも渡せる。gcc コマンドは -arch i386, -arch x86_64 のどれかを指定すると x86 用のプリプロセッサを呼び出し、-arch ppc, -arch ppc64 のどれかを指定すると ppc 用のプリプロセッサを呼び出す）。
|
||
</ul>
|
||
<p>GCC (GNU C) 版では、以下の（この 2.6 セクションの終わりまでの）オプションが使えます。なお、GCC 用では <tt>__STDC__</tt> は 1 にしているので、-S1 オプションは指定してもしなくても同じです。</p>
|
||
<p>まず、<b>mcpp</b> のモードによらないオプションは次のとおりです。</p>
|
||
<ul>
|
||
<li><samp>-$</samp><br>
|
||
-fno-dollars-in-identifiers と同じ。<br>
|
||
<li><samp>-b</samp><br>
|
||
行番号情報をＣのソースのスタイルで出力する。
|
||
<br>
|
||
プリプロセッサからコンパイラ本体への行番号情報の受け渡しは<br>
|
||
<pre>
|
||
#line 123 "filename"
|
||
</pre>
|
||
というＣのソースと同じ形式でできる処理系が普通であるが、この形式は使えない処理系もある。<b>mcpp</b> はそのような処理系用の build では、その処理系のコンパイラ本体の受け取れる形式で行番号情報を出力するのが、デフォルトの仕様である。<br>
|
||
しかし、これらの処理系専用版でも、このオプションを使うと、Ｃのソースのスタイルで行番号情報を出力する。<br>
|
||
このオプションは、出力をもう一度プリプロセスする時のためのもので、#pragma MCPP preprocess と組み合わせてヘッダファイルの「プリプリプロセス」をする時に使う。<br>
|
||
<li><samp>-dD, -dM</samp><br>
|
||
プリプロセスの最後にその時点で有効なマクロ定義を #define 行の形で出力する。-dM オプションではプリプロセス結果は出力しない。また、事前定義されたマクロも規格の標準事前定義マクロでなければ出力する。-dD オプションではプリプロセス結果も出力する。また、事前定義マクロは出力しない。*3, *4<br>
|
||
<li><samp>-fexceptions</samp><br>
|
||
マクロ <tt>__EXCEPTIONS</tt> を 1 に定義する。<br>
|
||
<samp>-fno-exceptions</samp> ではこのマクロを定義しない。<br>
|
||
<li><samp>-finput-charset=<encoding></samp><br>
|
||
-e <encoding> オプションと同じ。GCC はこのオプションを指定すると <encoding> を UTF-8 に変換するが、<b>mcpp</b> は変換はしないことに注意。<br>
|
||
<li><samp>-fno-dollars-in-identifiers</samp><br>
|
||
Identifier 中に '$' を認めない（デフォルトでは認める）。<br>
|
||
<li><samp>-fPIC, -fpic, -fPIE, -fpie</samp><br>
|
||
いずれもマクロ <tt>__PIC__, __pic__</tt> をともに 1 に定義する。<br>
|
||
<li><samp>-fstack-protector</samp><br>
|
||
マクロ <tt>__SSP__</tt> を 1 に定義する。<br>
|
||
<li><samp>-fstack-protector-all</samp><br>
|
||
マクロ <tt>__SSP_ALL__</tt> を 2 に定義する。<br>
|
||
<li><samp>-fworking-directory</samp><br>
|
||
出力の２行目にカレントディレクトリを表す特別な #line 行を出力する。<br>
|
||
<li><samp>-I-</samp><br>
|
||
このオプションの前と後とで -I <directory> オプションの仕様を変える。このオプションの前に -I で指定されたディレクトリは #include "header.h" の形のヘッダファイルのサーチにだけ使われる。このオプションの後で -I で指定されたディレクトリはすべての #include directive のサーチに使われる。また、#include "header.h" の形でも include 元のディレクトリはサーチしない。<br>
|
||
<li><samp>-include <file></samp><br>
|
||
メインのソースファイルを処理する前に、<file> を #include する（ソースの冒頭に #include <file> と書いたのと同じ結果になる）。<br>
|
||
<li><samp>-iquote <dir></samp><br>
|
||
<dir> を #include "header.h" の形式のヘッダファイルのサーチパスに加える。<br>
|
||
<li><samp>-isysroot=<dir>, -isysroot <dir>, --sysroot=<dir>, --sysroot <dir></samp><br>
|
||
<dir> を system header directory の root とみなす。
|
||
すなわち、<dir> を system header directory の path-list の頭に付ける。
|
||
例えば、include directory が /usr/include で <dir> が /Developer/SDKs/MacOSX10.4u.sdk であれば /Developer/SDKs/MacOSX10.4u.sdk/usr/include とする。<br>
|
||
<li><samp>-isystem <dir></samp><br>
|
||
<dir> をインクルードパスの system-specific な directory の前に（site-specific な directory の後に）加える。<br>
|
||
<li><samp>-lang-c, -x c</samp><br>
|
||
C のプリプロセスを行う。指定しなくても同じ。<br>
|
||
<li><samp>-mmmx</samp><br>
|
||
マクロ <tt>__MMX__</tt> を 1 に定義する。<br>
|
||
<samp>-mno-mmx</samp> では <tt>__MMX__</tt> を定義しない。<br>
|
||
<li><samp>-nostdinc</samp><br>
|
||
他の処理系での -I- オプションと同じ。<br>
|
||
<li><samp>-undef</samp><br>
|
||
-N オプションと同じ。<br>
|
||
<li><samp>-O?</samp><br>
|
||
? が 0 以外の数字であればマクロ <tt>__OPTIMIZE__</tt> を 1 に定義する。<br>
|
||
<li><samp>-Wcomment, -Wcomments, -Wsign-compare</samp><br>
|
||
-W1 オプションと同じ。指定しなくても同じ。<br>
|
||
<li><samp>-Wundef</samp><br>
|
||
-W4 オプションと同じ。<br>
|
||
<li><samp>-Wtrigraphs</samp><br>
|
||
-W16 オプションと同じ。<br>
|
||
<li><samp>-Wall</samp><br>
|
||
-W17 (-W1 -W16) オプションと同じ（class 2, 4 の warning は Linux 等の標準ヘッダでは頻発しやすくうるさいので、-Wall からはずしてある。class 8 の warning も通常は余計なお節介である。しかし、これらには portability を確かめる等の有用な使い道がある。使う時は gcc -Wp,-W31 とすること）。<br>
|
||
<li><samp>-w</samp><br>
|
||
-W0 オプションと同じ。<br>
|
||
</ul>
|
||
<p>GCC 版の Standard モードでは次のオプションが使えます。
|
||
</p>
|
||
<ul>
|
||
<li><samp>-ansi</samp><br>
|
||
<tt>__STRICT_ANSI__</tt> マクロを 1 に定義する。
|
||
<tt>linux, i386</tt> 等の規格違反の事前定義マクロを無効にする。
|
||
GCC 仕様の可変引数マクロの呼び出しでは、可変引数が存在しなくてもその直前のコンマを削除しない。*5
|
||
<br>
|
||
<li><samp>-digraphs</samp><br>
|
||
Digraph を認識する（-2 での反転も有効）。
|
||
<br>
|
||
<li><samp>-lang-c89, -std=gnu89</samp><br>
|
||
-S1 オプションと同じ。指定しなくても同じ。C90 だけでなく C95 の仕様も含まれる。<br>
|
||
<li><samp>-std=c89, -std=c90</samp><br>
|
||
-S1 オプションとほぼ同じであるが、-ansi を含意する。
|
||
<li><samp>-lang-c99, -lang-c9x, -std=gnu99, -std=gnu9x</samp><br>
|
||
-V199901L オプションと同じ。<br>
|
||
<li><samp>-std=c99, -std=c9x</samp><br>
|
||
-V199901L オプションとほぼ同じであるが、-ansi を含意する。<br>
|
||
<li><samp>-lang-c++, -x c++</samp><br>
|
||
C++ のプリプロセスを行う。-+ と同じ。<br>
|
||
<li><samp>-std=c++98</samp><br>
|
||
-+ とほぼ同じであるが、-ansi を含意する。<br>
|
||
<li><samp>-pedantic, -pedantic-errors</samp><br>
|
||
-W7 (-W1 -W2 -W4) オプションと同じ。
|
||
<br>
|
||
<li><samp>-std=iso<n>:<ym></samp><br>
|
||
規格のバージョンを指定する。<n> は C では 9899 であり、C++ では 14882 である。<n> が 9899 の場合は、<ym> は 1990, 199409, 1999, 199901 等である。<n> が 14882 の場合は、<ym> は 199711 である。<ym> にその他の値が指定された場合は、<tt>__STDC_VERSION__</tt> または <tt>__cplusplus</tt> がその値に定義される（この場合は 200503 というように６ケタで指定すること）。<br>
|
||
これらのオプションでは -ansi も指定したことになる。
|
||
他方で、-std=gnu* は -ansi を含意しない。
|
||
-pedantic も -ansi を含意しない。<br>
|
||
</ul>
|
||
<p>GCC 版の <i>STD</i> モードでは次のオプションが使えます。</p>
|
||
<ul>
|
||
<li><samp>-lang-asm, -x assembler-with-cpp</samp><br>
|
||
他の処理系での -a と同じ。
|
||
lang-asm モードにする。
|
||
GCC-specific-build ではマクロ <tt>__ASSEMBLER__</tt> が 1 に定義され、identifier 中に '$' は使えなくなる。
|
||
入力ファイルの名前が *.S であるときはこのオプションを指定しなくても、このモードになる。<br>
|
||
<li><samp>-trigraphs</samp><br>
|
||
Trigraph を認識する（-3 での反転も有効）。
|
||
<br>
|
||
</ul>
|
||
<p>GCC 版の pre-Standard モードでは次のオプションが使えます。
|
||
</p>
|
||
<ul>
|
||
<li><samp>-traditional, -traditional-cpp</samp><br>
|
||
-@old と同じ。
|
||
<br>
|
||
</ul>
|
||
<p>CygWIN / GCC 版では次のオプションが使えます。
|
||
</p>
|
||
<ul>
|
||
<li><samp>-mno-cygwin</samp><br>
|
||
Include directory の /usr/include を /usr/include/mingw に変更し、事前定義マクロを cygwin1.dll 用から msvcrt.dll 用に変更する。<br>
|
||
</ul>
|
||
<p>次のオプションはいずれもエラーにはしませんが、何も対応しません（ウォーニングを出す場合もある）。</p>
|
||
<ul>
|
||
<li><samp>-A <predicate(answer)></samp><br>
|
||
GCC ではこのオプションはソースに #assert <predicate(answer)> と書いたのと同じ結果になるが、#pragma でない拡張ディレクティブは Standard C では認められないものである。幸いいままでのところ gcc はデフォルトでは -D オプションで同等のマクロを cpp に渡してくれるので、実際にはほとんどの場合、支障はない（#assert を使っている稀なソースでない限り）。<br>
|
||
<li><samp>-g <n></samp><br>
|
||
<li><samp>-idirafter <dir></samp><br>
|
||
<li><samp>-iprefix <dir>, -iwithprefix <dir>, -iwithprefixbefore <dir></samp><br>
|
||
<li><samp>-noprecomp</samp><br>
|
||
<li><samp>-remap</samp><br>
|
||
</ul>
|
||
<p>GCC V.3.3 以降ではプリプロセッサがコンパイラに吸収されて独立したプリプロセッサが存在しなくなったため、gcc を -no-integrated-cpp オプションを付けて呼び出しても、プリプロセッサのオプションではないオプションがプリプロセッサに渡されてくることがあります。GCC V.3.3 以降用の <b>mcpp</b> では、次のようなもののうち <b>mcpp</b> の認識しないものはこの種のにせオプションとして無視します。</p>
|
||
<ul>
|
||
<li><samp>-c</samp><br>
|
||
<li><samp>-E</samp><br>
|
||
<li><samp>-f*</samp><br>
|
||
<li><samp>-m*</samp><br>
|
||
<li><samp>-quiet</samp><br>
|
||
<li><samp>-W*</samp><br>
|
||
</ul>
|
||
<p>注:</p>
|
||
<p>*1 -Wa はアセンブラ用の -Wl はリンカ用のオルマイティオプションである。
|
||
UNIX / System V / cc のマニュアルを見ると、やはりこれらのオプションがある。GCC / cc の -W<x> オプションはこれとの互換性のためのものなのであろう。</p>
|
||
<p>*2 GCC V.3 では cpp が cc1 (cc1plus) に吸収されてしまった。そのため、-Wp で指定したオプションは通常は cc1 (cc1plus) に渡されてしまう。プリプロセスを cc1 ではなく cpp (cpp0) にさせるためには、gcc の呼び出しに -no-integrated-cpp というオプションを指定する必要がある。</p>
|
||
<p>*3 ただし、GCC V.3.3 以降では大量のマクロが事前定義されるようになったが、これらは事前定義マクロとしては扱わない。すなわち、-dD オプションでもこれらのマクロを出力する。</p>
|
||
<p>*4 #pragma MCPP put_defines (#put_defines) の出力は -dM オプションとほぼ同様である。ただし、次の点が違っている。</p>
|
||
<ol>
|
||
<li>put_defines では標準事前定義マクロとして規定されているものも、コメントの形で出力する。<br>
|
||
<li>put_defines ではそのマクロ定義のあるファイル名と行番号もコメントの形で出力され、また読みやすいように形を整えて出力するが、-d* オプションでは GCC と同じ形式で出力する。この形式を想定している makefile も見掛けるからである。<br>
|
||
</ol>
|
||
<p>*5 <a href="#3.9.6.3">3.9.6.3</a> を参照のこと。</p>
|
||
<br>
|
||
|
||
<h2><a name="2.7" href="#toc.2.7">2.7. 環境変数</a></h2>
|
||
<p>Compiler-independent 版の <b>mcpp</b> では include ディレクトリは UNIX 系 OS での /usr/include, /usr/local/include 以外はデフォルトでは設定されていないので、他のディレクトリも必要であれば、環境変数や実行時オプションで指定しなければなりません。Compiler-independent 版の環境変数は C では INCLUDE、C++ では CPLUS_INCLUDE です。ファイルのサーチはデフォルトではソースファイルのあるディレクトリを基準とします（<a href="#4.2"> 4.2</a> を参照のこと）。しかし、Linux では include ディレクトリに混乱があるので、特別な対策が必要です。それについては <a href="#3.9.9"> 3.9.9</a> を参照してください。</p>
|
||
<p>GCC 専用版でデフォルトで設定されている system include ディレクトリについては、noconfig/*.dif ファイルを見てください。また、include ディレクトリのサーチ順と環境変数の名前については、<a href="#4.2"> 4.2</a> を見てください。</p>
|
||
<p>環境変数 LC_ALL, LC_CTYPE, LANG については、<a href="#2.8"> 2.8</a> を見てください。
|
||
</p>
|
||
<br>
|
||
|
||
<h2><a name="2.8" href="#toc.2.8">2.8. Multi-byte character の encoding</a></h2>
|
||
<p><b>mcpp</b> は multi-byte character の多様な encoding に対応しています。
|
||
</p>
|
||
<blockquote>
|
||
<table>
|
||
<tr><th>EUC-JP </th><td>日本の extended UNIX code (UJIS)</td></tr>
|
||
<tr><th>shift-JIS </th><td>日本の MS-Kanji</td></tr>
|
||
<tr><th>GB-2312 </th><td>中国の EUC-like な encoding （簡体字）</td></tr>
|
||
<tr><th>Big-Five </th><td>台湾の encoding （繁体字）</td></tr>
|
||
<tr><th>KSC-5601 </th><td>韓国の EUC-like な encoding (KSX 1001)</td></tr>
|
||
<tr><th>ISO-2022-JP1</th><td>国際規格の日本語</td></tr>
|
||
<tr><th>UTF-8 </th><td>unicode の encoding の１種</td></tr>
|
||
</table>
|
||
</blockquote>
|
||
<p>そして、実行時に次のようないくつかの方法で実際に使う encoding を指定します。優先順位はこの順のとおりです。</p>
|
||
<ol>
|
||
<li>ソース中で #pragma __setlocale( "<encoding>") で指定された encoding （Visual C 用では #pragma setlocale( "<encoding>") ）。これを使うと、１本のソースファイルの中でも複数の encoding を使うことができる。<br>
|
||
<li>実行時オプション -e <encoding> または -finput-charset=<encoding> で指定された encoding。<br>
|
||
<li>環境変数 LC_ALL, LC_CTYPE, LANG で指定された encoding（優先順位はこの順）。<br>
|
||
<li><b>mcpp</b> をコンパイルする時に設定されたデフォルトの encoding。<br>
|
||
</ol>
|
||
#pragma __setlocale、-e オプション、環境変数で指定できる <encoding> は原則として共通で、次のとおりです。右辺の <encoding> は左辺の encoding を指定します。<encoding> は大文字・小文字の区別をしません。また、'-', '_' は無視します。さらに '.' があると、そこまでをすべて無視します。したがって、たとえば EUC_JP, EUC-JP, EUCJP, euc-jp, eucjp, ja_JP.eucJP はすべて同じものとして扱われます。また、* は任意の文字を意味します（iso8859-1, iso8859-2 等は iso8859* にマッチする）。<br>
|
||
<br>
|
||
<blockquote>
|
||
<table>
|
||
<tr><th>EUC-JP </th><td>eucjp, euc, ujis</td></tr>
|
||
<tr><th>shift-JIS </th><td>sjis, shiftjis, mskanji</td></tr>
|
||
<tr><th>GB-2312 </th><td>gb2312, cngb, euccn</td></tr>
|
||
<tr><th>BIG-FIVE </th><td>bigfive, big5, cnbig5, euctw</td></tr>
|
||
<tr><th>KSC-5601 </th><td>ksc5601, ksx1001, wansung, euc<i>KR</i></td></tr>
|
||
<tr><th>IS0-2022-JP1</th><td>iso2022jp, iso2022jp1, jis</td></tr>
|
||
<tr><th>UTF-8 </th><td>utf8, utf</td></tr>
|
||
<tr><th>なし </th><td>c, en*, latin*, iso8859*</td></tr>
|
||
</table>
|
||
</blockquote>
|
||
<p>C, en* (english), latin*, iso8859* のどれかを指定すると、multi-byte character は認識されなくなります。ASCII ではない ISO-8859-* の Latin 系の single-byte character を使う時は、これを指定します。#pragma __setlocale( "") と空の名前を指定すると、デフォルトの encoding に戻ります。</p>
|
||
<p>このほか、Visual C++ 用の #pragma setlocale に限って、次のものも使えます。これらは Visual C++ との互換性のために用意しているものです。Visual C++ ではコンパイラがこちらでないと認識しないので、こちらを使ったほうが良いでしょう（'-' は <b>mcpp</b> では省略できるが、Visual C++ のコンパイラに対しては省略できない）。Visual C++ では C, english も使えます。</p>
|
||
<blockquote>
|
||
<table>
|
||
<tr><th>shift-JIS</th><td>japanese, jpn</td></tr>
|
||
<tr><th>GB-2312 </th><td>chinese-simplified, chs</td></tr>
|
||
<tr><th>BIG-FIVE </th><td>chinese-traditional, cht</td></tr>
|
||
<tr><th>KSC-5601 </th><td>korean, kor</td></tr>
|
||
</table>
|
||
</blockquote>
|
||
<p>Visual C++ では、Windows がどの国語用であるかによってデフォルトの multi-byte character encoding が変わることになっています。また、Windows の「地域と言語のオプション」の指定によっても変わりますが、この機能は中途半端でやっかいです。しかし、#pragma setlocale による指定はそれらに優先します。</p>
|
||
<p>GCC は shift-JIS, ISO2022JP, BIG-FIVE のように multi-byte character が 0x5c の値を持つバイトを含む encoding はうまく処理できない場合があるので、GCC 版では <b>mcpp</b> がそれを補います。*1</p>
|
||
<p>注:</p>
|
||
<p>*1 GCC を configure する時に --enable-c-mbchar というオプションを付けると、その GCC では環境変数 LANG を C-EUCJP, C-SJIS, C-JIS のどれかにセットすることによって encoding を指定できることになっている。
|
||
しかし、この configuration は 1998 からあるもののようであるが、実際には使われておらず、使っても正しく動作しない。
|
||
GCC 版の <b>mcpp</b> ではこれら LANG=C-SJIS 等の環境変数をサポートしていたが、V.2.7 で廃止した。<br>
|
||
GCC では LANG のほかに LC_ALL, LC_CTYPE でも encoding を指定できることになっているが、実際には診断メッセージが変わるだけである。</p>
|
||
<br>
|
||
|
||
<h2><a name="2.9" href="#toc.2.9">2.9. ワンパスコンパイラで <b>mcpp</b> を使うには</a></h2>
|
||
<p>Visual C, Borland C, LCC-Win32 のようにプリプロセッサがコンパイラから独立していないいわゆる「ワンパスコンパイラ」が多くなっています。処理速度を上げるためだと思われます。しかし、プリプロセスに要する時間は現在のハードウェアでは小さなものになっています。また、そもそもプリプロセスというものは実行時環境や処理系からはほぼ独立した共通のフェーズであることに大きな意味があるので、「ワンパスコンパイラ」が多くなるのは決して良いことだとは思えません。プリプロセスの処理系依存の仕様も増える結果になります。</p>
|
||
<p>ともあれワンパスコンパイラでは、プリプロセッサを <b>mcpp</b> に置き換えることができません。したがって、<b>mcpp</b> を使うには、まず <b>mcpp</b> でソースをプリプロセスし、その出力をコンパイラに渡しますが、コンパイラによって再度ムダにプリプロセスがされることになります。ムダですが、やむをえません。それでも、<b>mcpp</b> を使うことはソースチェックのために有効であり、処理系付属のプリプロセッサにはない機能を使うこともできます。<br>
|
||
ワンパスコンパイラで <b>mcpp</b> を使うには、この手順を makefile に書く必要があります。そのサンプルとしては、<b>mcpp</b> 自身のコンパイルに使う visualc.mak, borlandc.mak, lcc_w32.mak 等の makefile のリコンパイル用の設定を見てください。</p>
|
||
<p>なお、GCC 3, 4 ではコンパイラがプリプロセス機能を内蔵するようになったものの、外部プリプロセッサを使うオプションも用意されているので、それを活用することで <b>mcpp</b> を問題なく使うことができます（<a href="#3.9.7">3.9.7</a> 参照）。</p>
|
||
<br>
|
||
|
||
<h2><a name="2.10" href="#toc.2.10">2.10. 統合開発環境で <b>mcpp</b> を使うには</a></h2>
|
||
<p>GUI のいわゆる「統合開発環境」(IDE) というものは処理系独自の仕様であり、内部的なインタフェースも通常は公開されていないので、その中で <b>mcpp</b> を使うには困難があります。その上、コンパイラがワンパスコンパイラであると、そこに <b>mcpp</b> を使うフェーズを挿入するのはさらに困難です。</p>
|
||
<p>ここでは Windows 上の Visual C++ 2003, 2005, 2008 の IDE で <b>mcpp</b> を使う方法を説明します。Borland C 版や LCC-Win32 版は、コマンドラインで使ってください。</p>
|
||
<p>また、Mac OS X の Xcode.app / Apple-GCC で <b>mcpp</b> を使う方法も説明します。</p>
|
||
|
||
<h3><a name="2.10.1" href="#toc.2.10.1">2.10.1. Visual C++ の IDE で <b>mcpp</b> を使う方法</a></h3>
|
||
<p>Visual C++ の IDE は内部的なインタフェースが公開されておらず、しかもコンパイラがワンパスコンパイラなので、通常の「プロジェクト」では <b>mcpp</b> を使うことができません。しかし、<b>mcpp</b> を使う makefile を書いておけば、それを取り込んで「メイクファイルプロジェクト」を作成することができます。そして、ソースの編集や検索や、さらにソースレベルデバッグ機能を含む IDE の大半の機能を使うことができます。</p>
|
||
<p>「メイクファイルプロジェクト」を作るには次のようにします。この方法は 「Visual C++ .net 2003 ドキュメント」および「Visual C++ 2005 Express Edition」「Visual C++ 2008 Express Edition」の「ヘルプ」の「メイクファイルプロジェクトの作成」に書いてあるものです。</p>
|
||
<ol>
|
||
<li>IDE のデバッグ機能を使う権限を持つユーザとしてログインする。*1<br>
|
||
<li><b>mcpp</b> を使う makefile を書いておく（noconfig/visualc.mak を参照）。*2<br>
|
||
<li>Visual Studio を起動する。*3<br>
|
||
<li>「新しいプロジェクト」をクリックし、
|
||
現れた「新しいプロジェクト」のウィンドウで「メイクファイル プロジェクト」を選び、「プロジェクト名」と「場所」を指定して「OK」をクリックする。<br>
|
||
<li>すると、「メイクファイル アプリケーション ウィザード」のウィンドウが開くので、「アプリケーションの設定」をクリックし、そこで「ビルドコマンドライン」「出力」「クリーンコマンド」（または「消去コマンド」）「リビルドコマンド」の欄を入力する。これらの用語はわかりにくいが、<b>mcpp</b> 自身の compiler-independent 版のコンパイルを例にとると次のようなことである（生成する <b>mcpp</b> の実行プログラムの名前を mcpp.exe とする）。<br>
|
||
<pre>
|
||
「ビルドコマンドライン」: nmake
|
||
「出力」 : mcpp.exe
|
||
「クリーンコマンド」 : nmake clean
|
||
「リビルドコマンド」 : nmake PREPROCESSED=1
|
||
</pre>
|
||
<b>mcpp</b> の Visual C 専用版をコンパイルする場合は COMPILER=MSC というオプションを付け加えて次のようにする。<br>
|
||
<pre>
|
||
「ビルドコマンドライン」: nmake COMPILER=MSC
|
||
「出力」 : mcpp.exe
|
||
「クリーンコマンド」 : nmake clean
|
||
「リビルドコマンド」 : nmake PREPROCESSED=1 COMPILER=MSC
|
||
</pre>
|
||
「メイクファイルプロジェクト」では make install に相当するコマンドがないので、「ビルドコマンドライン」「リビルドコマンド」で指定されるコマンドでは install も実行されるように makefile を書いておく必要がある。*4<br>
|
||
<b>mcpp</b> をコンパイルするのでなければ、「ビルドコマンドライン」と「リビルドコマンド」とは通常は同一で良い。<br>
|
||
これらを入力したら、「完了」をクリックする。<br>
|
||
<li>すると、
|
||
「ソリューションエクスプローラ」にプロジェクトが現れるので、その「ソースファイル」というフォルダをクリックして、そして、メニューの「プロジェクト」から「既存項目の追加」を選び、ソースファイルをすべて選択して「OK」する。すると、「ソリューションエクスプローラ」にソースファイル名が現れる。<br>
|
||
</ol>
|
||
<p>これで、「編集」「ビルド」「リビルド」「デバッグ」等の機能がすべて使えるようになります。</p>
|
||
<p>注:</p>
|
||
<p>*1 VC 2003, 2005 でデバッグ機能を使うためには、WindowsXP Pro, Windows2000 では "Debugger users" というグループにユーザを所属させる必要がある。WindowsXP HE ではそういうグループはないので、管理者としてログインしなければならない。<br>
|
||
VC 2008 ではユーザグループの制限はなくなった。</p>
|
||
<p>*2 ソースレベル・デバッグ機能を使うためには cl.exe の呼び出しに -Zi オプションを付加して、デバッグ情報が生成されるように makefile を書いておく必要がある。</p>
|
||
<p>*3 「スタート」->「プログラム」から起動すると、インクルードディレクトリ等の環境変数が設定されない。これを設定するには先に「Visual Studio コマンドプロンプト」を開いて、ソースファイルのあるディレクトリに移動し、そこから VC 2003 では</p>
|
||
<pre>
|
||
devenv *.sln /useenv
|
||
</pre>
|
||
<p>として、VC 2005, 2008 express edition では</p>
|
||
<pre>
|
||
vcexpress *.sln /useenv
|
||
</pre>
|
||
<p>として起動しなければならない。</p>
|
||
<p>*4 インストールするディレクトリにはユーザが書き込みの権限を持っていなければならない。
|
||
処理系の bin, lib 等のディレクトリに書き込む時は、そのパーミッションを管理者権限で変更しておく必要がある。
|
||
"Power users" または "Authenticated users" というグループにユーザを登録し、このグループに該当のディレクトリへの「書き込み」「変更」の権限を持たせるのが良い。
|
||
もう１つの方法は、「共有ディレクトリ」のような、ユーザが書き込み権限を持つディレクトリに処理系をインストールすることである。</p>
|
||
|
||
<h3><a name="2.10.2" href="#toc.2.10.2">2.10.2. Mac OS X / Xcode.app で <b>mcpp</b> を使う方法</a></h3>
|
||
<p>Mac OS X の IDE である Xcode.app は <b>mcpp</b> をインストールした状態で問題なく使うことができます。*1</p>
|
||
<p>Xcode.app はなぜか /usr/bin ではなく /Developer/usr/bin にある gcc (g++) を使います（/Developer は Xcode のデフォルトのインストールディレクトリ）。
|
||
したがって、<b>mcpp</b> を使うには、その gcc (g++) 用の GCC-specific-build をインストールする必要があります。
|
||
そのためには次のようにします（${mcpp_dir} は <b>mcpp</b> のソースのあるディレクトリ）。</p>
|
||
<pre>
|
||
export PATH=/Developer/usr/bin:$PATH
|
||
configure ${mcpp_dir}/configure --enable-replace-cpp
|
||
make
|
||
sudo make install
|
||
</pre>
|
||
<p>PATH の設定以外は /usr/bin のコンパイラにインストールする場合と同じなので、クロスコンパイラへのインストールや universal binary をインストールする方法などについては、INSTALL-jp を見てください。</p>
|
||
<p>こうして <b>mcpp</b> をインストールしておけば、あとは <b>mcpp</b> のための特別な設定はせずに Xcode.app が使えます。
|
||
Xcode.app は Apple-GCC 特有な *.hmap という名前の "header map file" なるものを生成しますが、これも <b>mcpp</b> で処理されます。
|
||
ただし、<b>mcpp</b> は precompiled header の処理はしないので、<samp>#include *.pch</samp> は通常のヘッダファイルとして読み込まれます。
|
||
また、<b>mcpp</b> は Objective-C, Objective-C++ の処理はしないので、*.m, *.mm のソースファイルのプリプロセスは <b>mcpp</b> を通らずに cc1obj, cc1objplus に直接、渡されます。</p>
|
||
<p><b>mcpp</b> 独自のオプションを使う場合は、Xcode.app の画面トップのメニューバーの「プロジェクト」から「プロジェクト設定を編集」を選んでクリックし、そこで現れるプロジェクトエディタのウィンドウで「ビルド」ペインを選んで、「その他の C フラグ」の項目を編集します。
|
||
オプションは次の例のように -Wp, に続けてコンマで区切りながら指定します。</p>
|
||
<pre>
|
||
-Wp,-23,-W3
|
||
</pre>
|
||
<p>注:</p>
|
||
<p>*1 ここで取り上げるのは Mac OS X Leopard / Xcode 3.0 である。</p>
|
||
<br>
|
||
|
||
<h1><a name="3" href="#toc.3">3. 拡張機能と互換性</a></h1>
|
||
<p><b>mcpp</b> にはいくつかの固有の拡張機能があります。また、各処理系付属のプリプロセッサにはそれぞれの拡張機能がありますが、それらの一部は <b>mcpp</b> では使えません。ここではこうした拡張機能と互換性の問題を説明します。</p>
|
||
<p>なお、Standard モードでは #pragma 行は原則としてそのまま出力します。<b>mcpp</b> 自身が処理するものについても同様です。同じ #pragma がコンパイラ本体にとっても意味を持つ可能性があるためです。<br>
|
||
しかし、#pragma MCPP で始まる行は <b>mcpp</b> 専用のものなので出力しません。GCC 版では、#pragma GCC に poison, dependency, system_header のどれかが続く行も出力しません。また、#pragma once, #pragma push_macro, #pragma pop_macro もコンパイラ本体にとっては無用なので出力しません。
|
||
他方で、#pragma GCC visibility * はコンパイラとリンカのためのものなので、出力します。*1</p>
|
||
<p><i>EXPAND_PRAGMA</i> == <i>TRUE</i> でコンパイルされた <b>mcpp</b> では #pragma 行の引数はマクロ展開の対象となります（実際には <i>EXPAND_PRAGMA</i> == <i>TRUE</i> は Visual C, Borland C 版だけである）。ただし、#pragma に STDC, MCPP, GCC のどれかが続く行は展開しません。</p>
|
||
<p>#pragma sub-directive は implementation-defined ですが、そのため同じ名前の sub-directive が処理系によって異なる意味を持つ恐れがあります。名前の衝突を避ける工夫が必要です。また、<i>EXPAND_PRAGMA</i> == <i>TRUE</i> の場合は、#pragma sub-directive の名前自身がマクロ展開されては困るので、ユーザの名前空間と重ならないようにする仕組みも必要です。<b>mcpp</b> 固有の sub-directive が #pragma MCPP で始まりマクロ展開されないのはこのためです。C99 で規定された #pragma STDC や GCC 3 の #pragma GCC の方法を採り入れたものです。<br>
|
||
ただし、#pragma once は多くの処理系に実装されて名前が衝突する恐れはなくなっているので、この名前のまま実装しています。また、#pragma __setlocale はコンパイラ本体に対しても必要なので MCPP という名前は付けず、"__" を先頭に付けてユーザの名前空間と重ならないようにしています。</p>
|
||
<p>注</p>
|
||
<p>*1 <b>mcpp</b> の GCC-specific-build では、#pragma GCC で始まる pragma のうち system_header だけサポートしている。poison, dependency はサポートしない。</p>
|
||
<br>
|
||
|
||
<h2><a name="3.1" href="#toc.3.1">3.1. #pragma MCPP put_defines, #pragma MCPP preprocess 等</a></h2>
|
||
<p>#pragma MCPP put_defines, #pragma MCPP preprocess, #pragma MCPP preprocessed は Standard モードのもので、#put_defines, #preprocess, #preprocessed は pre-Standard モードのものです。以下では #pragma を例にとって説明します。</p>
|
||
<p>#pragma MCPP put_defines ディレクティブに出会うと <b>mcpp</b> は、その時点で定義されているすべてのマクロを #define 行の形で出力します。もちろん、#undef されたものは出てきません。<tt>__STDC__</tt> 等の #define, #undef の対象にできないものは、一応 #define 行の形をとって、しかしコメントマークで囲んで出力されます（<tt>__FILE__</tt>, <tt>__LINE__</tt> はマクロ呼び出し時に動的に定義される特殊なマクロなので、ここで出力される置換リストは無意味なものである）。<br>
|
||
pre-Standard モードおよび <i>POSTSTD</i> モードでは、function-like マクロ定義のパラメータ名は記憶しません。そこでこのディレクティブでは、パラメータ名は第１パラメータから順に機械的に a, b, c, ... という名前で表示します。27 個目以降のパラメータには a1, b1, c1, ..., a2, b2, c2, ... という名前を使います。</p>
|
||
<p><b>mcpp</b> を入力ファイルも出力ファイルも指定せずに起動して、キーボードからいきなり</p>
|
||
<pre>
|
||
#pragma MCPP put_defines
|
||
</pre>
|
||
<p>と打ち込むと、事前定義マクロをすべて知ることができます。それぞれのマクロ定義のあるソースファイル名と行番号を表示するコメントも出力されます。-S1, -N 等のオプションを付けて起動すると、それぞれ事前定義マクロが違ってくることがわかります。</p>
|
||
<p>#pragma MCPP preprocess というディレクティブに出会うと <b>mcpp</b> は、</p>
|
||
<pre>
|
||
#pragma MCPP preprocessed
|
||
</pre>
|
||
<p>という行を出力します。これは、このソースファイルはプリプロセス済みであることを示すものです。</p>
|
||
<p>#pragma MCPP preprocessed というディレクティブに出会うと <b>mcpp</b> は、そのソースファイルは <b>mcpp</b> によってプリプロセス済みであると判断して、#define 行が出てくるまでは入力をそのまま出力にコピーします。そして、#define 行が出てくると、あとはすべて #define 行であると判断して、マクロを定義します。コメント中にあるソースファイル名と行番号の情報も記憶します。*1, *2<br>
|
||
#pragma MCPP preprocessed の有効範囲はそのディレクティブのあるソースファイルのその行以降だけです。そのソースファイルが #include されたものである場合は、include 元に戻ると通常のプリプロセスに戻ります。</p>
|
||
<p>注:</p>
|
||
<p>*1 実際の処理はもう少し複雑である。#pragma MCPP preprocessed があると入力行の大半をそのまま出力にコピーするが、標準事前定義マクロは #define 行がコメントマークに囲まれているので、その行は捨てる。また、特定の処理系用の版では #line 行は処理系のコンパイラ本体が受け取れる形式に変換して出力する。</p>
|
||
<p>*2 したがって、pre-preprocess してもマクロ定義の場所の情報は失われない。</p>
|
||
|
||
<h3><a name="3.1.1" href="#toc.3.1.1">3.1.1. ヘッダファイルの pre-preprocess</a></h3>
|
||
<p>上記のディレクティブを利用すると、ヘッダファイルの「プリプリプロセス」をすることができます。「プリプリプロセス」をしておくと、本番のプリプロセス時間がかなり短縮されます。その方法は、上記の仕様ですでにわかったかと思いますが、念のために <b>mcpp</b> 自身のソースを例にとって説明します。</p>
|
||
<p><b>mcpp</b> のソースには８本の *.c ファイルがあり、そのうちの７本はどれも "system.H" と "internal.H" を include しています。そして、他のヘッダは include していません。もっと正確に言うと、ソースではこうなっています。</p>
|
||
<pre>
|
||
#if PREPROCESSED
|
||
#include "mcpp.H"
|
||
#else
|
||
#include "system.H"
|
||
#include "internal.H"
|
||
#endif
|
||
</pre>
|
||
<p>そして、system.H は noconfig.H または configed.H といくつかの標準ヘッダを include しています。mcpp.H は私の提供するソースにはありません。これが、これから生成する "pre-pre-processed" header なのです。</p>
|
||
<p>mcpp.H を生成するには（もちろん noconfig.H 等の設定がすんでから）、</p>
|
||
<pre>
|
||
mcpp > mcpp.H
|
||
</pre>
|
||
<p>として <b>mcpp</b> を起動します（GCC 等では、-b オプションも付ける）。<br>
|
||
そして、キーボードから</p>
|
||
<pre>
|
||
#pragma MCPP preprocess
|
||
#include "system.H"
|
||
#include "internal.H"
|
||
#pragma MCPP put_defines
|
||
</pre>
|
||
<p>と打ち込み、end-of-file を入力して <b>mcpp</b> を終了します。</p>
|
||
<p>これで mcpp.H ができあがりました。これは system.H, internal.H をプリプロセスしたものの末尾に #define 行の集合を付け加えたものです。これを include すれば、system.H, internal.H を include したのとまったく同じ効果を得ることができます。そして、これは標準ヘッダを含む元のヘッダファイルの総計の数分の１のサイズになっています。#if とコメントが消えているからです。これを７本の *.c ファイルで include するのは、system.H, internal.H を７回 include するのに比べて、はるかに短い時間ですみます。#pragma MCPP preprocess を使うことでさらに時間が短縮されます。</p>
|
||
<p>本番のコンパイルでは -DPREPROCESSED=1 というオプションを付けます。<br>
|
||
この手順は何かのファイルに書いておいて、makefile でそれを参照するのが良いでしょう。<b>mcpp</b> のソースに付けた makefile と preproc.c には、それが書いてあるので、そちらを見てください。<br>
|
||
Visual C, Borland C, LCC-Win32 のような１パス・コンパイラでは独立したプリプロセッサの使い道は制限されますが、その場合でもこの機能は有用です。</p>
|
||
<p>このヘッダファイルの pre-preprocess の機能は、GCC / cpp の -dD オプションの機能を真似たものです。ただし、次の点が違っています。</p>
|
||
<ol>
|
||
<li>GCC は行番号情報を #line 123 "filename" ではなく # 123 "filename" の形で出力する。このため、それを GCC で再処理することはできるが、Standard C のプリプロセッサではできない。<br>
|
||
<li>GCC の古い cpp では #define 行は出現したところで出力されるが、#undef 行は出力されない。したがって、これを再処理すると元ソースの意図と異なる結果になることがあった。<br>
|
||
<li>GCC にはない #pragma MCPP preprocess を使うことで、さらに速度が速くなる。<br>
|
||
</ol>
|
||
Pre-preprocess の機能としては、<b>mcpp</b> のほうが間違いがなく実用的です。<br>
|
||
<br>
|
||
|
||
<h2><a name="3.2" href="#toc.3.2">3.2. #pragma once</a></h2>
|
||
<p>#pragma once は Standard モードで使えます。<br>
|
||
GCC, Visual C, LCC-Win32 および Wave という単体プリプロセッサでも #pragma once は使えます。<br>
|
||
ヘッダファイルを１回しかインクルードしたくない時に使います。ヘッダファイルの中に</p>
|
||
<pre>
|
||
#pragma once
|
||
</pre>
|
||
<p>と書いておくと、そのファイルをインクルードする #include 行が何回出てきても、最初の１回しかインクルードしません。</p>
|
||
<p>通常は、処理系付属の標準ヘッダでは</p>
|
||
<pre>
|
||
#ifndef __STDIO_H
|
||
#define __STDIO_H
|
||
/* stdio.h の中身 */
|
||
#endif
|
||
</pre>
|
||
<p>等の皮でくるんで多重定義を防いでいますが、それと似た機能です。しかし、マクロを使う方法ではヘッダファイルを読まないですますことはできません（スキップする部分でも、#if, #endif 等が出てくるのを監視するために、全部読まなければならない。行頭の # がディレクティブ行（# に preprocessing directive が続く行）の指示であるかどうかを確かめるためにはコメントも処理しなければならないし、そのためには文字列リテラルも判断しなければならない等で、結局、全部読んで tokenization の大半までやらなければならないのである）。<br>
|
||
#pragma once は、ファイルへのアクセスさえもしないですますものです。その結果、多重 include がある場合の処理速度がやや速くなります。</p>
|
||
<p>Header name が同じであるかどうかは、サーチしたパスのディレクトリ部分も含めて文字の比較で判断します。ただし、Windows では大文字・小文字は区別しません。したがって、"/DIR1/header.h" と "/DIR2/header.h" は別のものとして扱い、"header.h" と "HEADER.H" とは Windows では同じもの、UNIX 系では別のものとして扱います。ディレクトリは絶対パスに変換して記憶します。<samp>"foo/../"</samp> といった冗長な部分は削除して正規化します。UNIX 系では symbolic link はリンク先に変換します。したがって、同じファイルであるかどうかは確実に判定されます。*1, *2, *3</p>
|
||
<p>この #pragma once は GCC V.1.* / cpp の #pragma once のアイデアを借用したものです。GCC V.2.*, V.3.* でもこの機能は残っていますが、obsolete なものとされています。#pragma once がなくても、ヘッダファイルの全体が #ifndef _MACRO, #define _MACRO, #endif で囲まれていれば、cpp がこれを記憶し、１回しか include しないという仕様に変更されています。<br>
|
||
しかし、GCC V.2, V.3 の仕様は、GCC の使用を前提としない市販の処理系などでは使えないことがあります。標準ヘッダの書き方が違っているからです。また、実装も GCC V.2, V.3 の仕様のほうが面倒です。そこで、<b>mcpp</b> では #pragma once だけを実装しています。</p>
|
||
<p>他のプリプロセッサでも同じヘッダファイルを使う場合はこれだけに頼るわけにはゆきません。マクロを使う方法と併用して、ヘッダファイルを次のような皮でくるんでおくのが良いでしょう。</p>
|
||
<pre>
|
||
#ifndef __STDIO_H
|
||
#define __STDIO_H
|
||
#pragma once
|
||
/* stdio.h の中身 */
|
||
#endif
|
||
</pre>
|
||
<p>ただし、<assert.h> には #pragma once は書いてはいけません（その理由は <a href="cpp-test.html#5.1.2"> cpp-test.html#5.1.2</a> 参照）。C++ の <cassert>, <cassert.h> 等も同様です。</p>
|
||
<p>もう一つの問題は、GCC / GLIBC の最近のシステムでは <stddef.h> のように、他の system header から繰り返し #include されるヘッダファイルがあることです。多くの system header が <tt>__need_NULL</tt>, <tt>__need_size_t</tt>, <tt>__need_ptrdiff_t</tt>, etc. のマクロを定義しては <stddef.h> を #include します。そのたびに、<stddef.h> では <tt>NULL</tt>, size_t, ptrdiff_t, etc. が定義されてゆきます。<errno.h>, <signal.h> 等も同様です。<stdio.h> でさえも、他の system header が <tt>__need_FILE, __need___FILE</tt> 等のマクロを定義しては #include <stdio.h> し、そのたびに FILE 等が定義されてゆく場合があります。これらのファイルには #pragma once は書き込むわけにはいきません。*4</p>
|
||
<p>注:</p>
|
||
<p>*1 正規化された結果は <samp>#pragma MCPP debug path</samp> で見ることができる。<a href="#3.5.1">3.5.1</a> 参照。
|
||
<samp>#pragma MCPP put_defines</samp> や診断メッセージのファイル名の表示でも、これが使われる。<br>
|
||
しかし、#line 行の path-list は一般には正規化されているわけではなく、include directory だけ正規化した状態で表示される。
|
||
ただし、-K オプションでは正規化して表示される。
|
||
このモードを利用する他のツールの処理を用意にするためである。</p>
|
||
<p>*2 CygWIN では /bin と /usr/bin、/lib と /usr/lib はそれぞれ同じディレクトリで、/ が Windows 上の例えば C:/dir/cygwin だとすると /cygdrive/c/dir/cygwin もそれと同じディレクトリであるが、<b>mcpp</b> ではこれらはすべて同じディレクトリとして扱う。path-list はすべて /cygdrive/c/dir/cygwin/dir-list/file の形に変換する。</p>
|
||
<p>*3 MinGW では / と /usr とは実際には同じディレクトリで、/ が Windows 上の C:/dir/msys/1.0 だとすると /c/dir/msys/1.0 もそれと同じディレクトリで、/mingw が C:/dir/mingw だとすると /c/dir/mingw もそれと同じディレクトリである。<b>mcpp</b> ではこれらはそれぞれ同じディレクトリとして扱う。path-list はすべて c:/dir/msys/1.0/dir-list/file, c:/dir/mingw/dir-list/file の形に変換する。</p>
|
||
<p>*4 少なくとも Linux / GCC 2.9x, 3.*, 4.* / glibc 2.1, 2.2, 2.3 ではそうなっている。FreeBSD 4, 5, 6 では glibc は使われていないので、こういう複雑なシステムヘッダにはなっていない。</p>
|
||
|
||
<h3><a name="3.2.1" href="#toc.3.2.1">3.2.1. ヘッダファイルに #pragma once を書き込むツール</a></h3>
|
||
<p>これを書き込むのはヘッダファイルの数が少なければ大したことではありませんが、数が多いと手ではうっとおしい作業になります。そこで、これを自動的に書き込む簡単なツールを用意しました。</p>
|
||
<p>tool/ins_once.c は古い GCC のシステム用です。Borland C 5.5 でも標準ヘッダの書き方は同じルールに従っているので、これを使うことができます。Glibc 2 のようなシステムでは上記のように例外が多いので、使わないほうが無難です。<br>
|
||
ただし、これが使えるシステムでも、ヘッダファイルの中には GCC の慣習に従っていないものも散見されます。そうしたヘッダでは GCC の、１回しか読み込まないという機能も動作しません。<br>
|
||
そこで、ins_once.c をコンパイルして、UNIX なら /usr/include, /usr/local/include 等のディレクトリで、まず</p>
|
||
<pre>
|
||
chmod -R u+w *
|
||
</pre>
|
||
<p>とした上で、</p>
|
||
<pre>
|
||
ins_once -t *.h */*.h */*/*.h
|
||
</pre>
|
||
<p>とします。そうすると、#ifndef または #if !defined で始まらないヘッダファイルが報告されます。それらのヘッダを手で修正してください。それから、</p>
|
||
<pre>
|
||
ins_once *.h */*.h */*/*.h
|
||
</pre>
|
||
<p>とすると、各ヘッダファイルの最初に出現する #directive が #ifndef または #if !defined であった場合は、その直後に #pragma once 行が書き込まれます。（これができるのは root と特定のユーザだけのはず。さらに必要なら chmod -R u-w * として、access permission を元に戻しておく）。</p>
|
||
<p>ins_once には次のようなオプションがあります。システムに合わせて適当なオプションを選択してください。</p>
|
||
<ul>
|
||
<li>-t: ファイルが（コメントを除くと）#ifndef か #if !defined で始まっているかどうかをテストする。ファイルは書き換えない。<br>
|
||
<li>-p: ファイルの冒頭に #pragma once 行を書き込む（デフォルトでは #ifndef / #if !defined 行の次に書き込む）。<br>
|
||
<li>-g: GCC のために、<stddef.h>, <stdio.h>, <signal.h>, <errno.h> も書き換えない（デフォルトでは書き換えないのは <assert.h>, <cassert>, <cassert.h> だけ）。<br>
|
||
</ul>
|
||
<p>ins_once は複数回実行しても同じファイルにダブって書き込むことはないように、簡単なチェックはしています。しかし、厳密なものではありません。</p>
|
||
<p>この ins_once は間に合わせなので、tokenization はほとんどやっていません。FreeBSD 2.0, 2.2.7, Borland C 5.5 の各ヘッダファイルでは期待通りの動作をしましたが、特殊なヘッダファイルがあると誤動作するかもしれません。ins_once は必ずバックアップをとってから実行してください。<br>
|
||
ワイルドカードは shell に展開させてください（バッファがオーバーフローする場合は、何回かに分けて実行する）。</p>
|
||
<br>
|
||
|
||
<h2><a name="3.3" href="#toc.3.3">3.3. #pragma MCPP warning, #include_next, #warning</a></h2>
|
||
<p>これらのディレクティブは GCC との互換性のために用意されているものです。GCC には #include_next, #warning という規格違反のディレクティブがあります。規格違反ですが、これを使っているソースも稀にあります。Glibc 2 のシステムでは、システムヘッダファイルにこれを使っているものさえあります。そこで <b>mcpp</b> では、これらのソースをコンパイルできるようにするため、GCC 用に限って #include_next, #warning を実装しています。ただし、Standard モードではウォーニングの対象となります。Standard モードでは #pragma MCPP warning も実装しています。これは GCC 用に限りません。</p>
|
||
<pre>
|
||
#include_next <header.h>
|
||
</pre>
|
||
<p>は include directory をサーチする際に、この include 元のファイルのあるディレクトリをスキップして、その次のサーチ順のディレクトリからサーチを始めます。</p>
|
||
<p>CygWIN, MinGW では、ヘッダ名の大文字・小文字の区別は無視します。</p>
|
||
<pre>
|
||
#pragma MCPP warning any message
|
||
|
||
#warning any message
|
||
</pre>
|
||
<p>では、any message をそのまま warning として標準エラー出力に出力します。しかし、これは #error と違ってエラーにはなりません。</p>
|
||
<br>
|
||
|
||
<h2><a name="3.4" href="#toc.3.4">3.4. #pragma MCPP push_macro, #pragma __setlocale 等</a></h2>
|
||
<p>これらは Visual C に <b>mcpp</b> を移植した時に実装し、ついでに他の処理系でも使えるようにしたものです。</p>
|
||
<p>#pragma MCPP push_macro( "MACRO"), #pragma MCPP pop_macro( "MACRO") は、その時点での MACRO のマクロ定義をスタックに "push" したり "pop" したりするものです。<br>
|
||
Visual C では #pragma push_macro( "MACRO"), #pragma pop_macro( "MACRO") も使えます。<br>
|
||
push_macro ではそのマクロの定義が退避され、pop_macro で元に戻されますが、push してもそのマクロ定義はまだ有効です。これを無効にするためには #undef するか、または別の定義で再定義する必要があります。push_macro では同じ名前のマクロを何重にも push することができます。</p>
|
||
<p>#pragma __setlocale( "<encoding>") は multi-byte character encoding を <encoding> に変更します。__setlocale の引数は文字列リテラルでなければなりません。<encoding> については <a href=#2.8>2.8</a> を見てください。これを使うと、１つの translation unit の中でも複数の encoding を使うことができます。<br>
|
||
Visual C++ では #pragma setlocale であり、#pragma __setlocale は使えません。Encoding の指定は <b>mcpp</b> だけでなく、コンパイラにも伝える必要がありますが、コンパイラが認識できるのは #pragma setlocale だけだからです。</p>
|
||
<p>#pragma __setlocale を認識できるコンパイラ本体はいまのところ、ありません。</p>
|
||
<br>
|
||
|
||
<h2><a name="3.5" href="#toc.3.5">3.5. #pragma MCPP debug, #pragma MCPP end_debug, #debug, #end_debug</a></h2>
|
||
<p>#pragma MCPP debug, #pragma MCPP end_debug は Standard モードのものです。pre-Standard モードでは #debug, #end_debug となります。</p>
|
||
<p>#pragma MCPP debug <args> ディレクティブはソース中の任意の行に書くことができます。<args> でデバッグ情報の種類を指定します。１つの #pragma MCPP debug ディレクティブで複数の <arg> を指定することができます。必ず１つ以上の <arg> 指定が必要です。このディレクティブがあると、そこからデバッグ情報の出力が始まります。そして、#pragma MCPP end_debug <args> で、<args> のデバッグ情報出力が解除されます。#pragma MCPP end_debug では、<args> を省略することができます。その場合は、設定されていたすべてのデバッグ情報出力が解除されます。<b>mcpp</b> でサポートしない引数が <args> にあった時は、ウォーニングを出しますが、その前にあった正しい引数は有効です。<br>
|
||
デバッグ情報はすべて、プリプロセスの本来の出力と同じパスに出力されます。これは本来の出力と同期させるためです。したがって、このディレクティブがあると通常はコンパイルできません。
|
||
ただし、#pragma MCPP debug macro_call では情報はコメントに埋め込んで出力されるので、それを再プリプロセスしてコンパイルすることができます。</p>
|
||
<p>プリプロセスの結果に疑問がある場合、その部分を</p>
|
||
<pre>
|
||
#pragma MCPP debug token expand
|
||
/* デバッグしたい部分 */
|
||
#pragma MCPP end_debug
|
||
</pre>
|
||
<p>というふうにはさんで使います。
|
||
</p>
|
||
<p>元来は <b>mcpp</b> 自身のデバッグ用のものですが、プリプロセスの過程をトレースしたい時に使えます。元来の目的が目的なので、ソースを見ないと理解できないところもあり、少々うるさくもありますが、がまんしてください。</p>
|
||
<p><arg> の種類は次の通りです。</p>
|
||
<blockquote>
|
||
<table>
|
||
<tr><th>path </th><td>include ファイルのサーチパスを表示する</td></tr>
|
||
<tr><th>token </th><td>token を１つずつ切り分けて、その種類を表示する</td></tr>
|
||
<tr><th>expand </th><td>マクロ呼び出しの展開過程をトレースする</td></tr>
|
||
<tr><th>macro_call</th><td>マクロ定義およびマクロ呼び出しに際して、そのソース上の行とカラム位置をコメントに埋め込んで出力する</td></tr>
|
||
<tr><th>if </th><td>#if (#elif, #ifdef, #ifndef) の真偽を表示する</td></tr>
|
||
<tr><th>expression</th><td>#if 式の評価をトレースする</td></tr>
|
||
<tr><th>getc </th><td>プリプロセスを 1 byte ずつトレースする</td></tr>
|
||
<tr><th>memory </th><td><b>mcpp</b> の使っているヒープメモリの状況を表示する</td></tr>
|
||
</table>
|
||
</blockquote>
|
||
<br>
|
||
|
||
<h3><a name="3.5.1" href="#toc.3.5.1">3.5.1. #pragma MCPP debug path, #debug path</a></h3>
|
||
<p>このディレクティブに出会うと <b>mcpp</b> は、まず設定されている include ディレクトリのサーチパスを優先順位の高いものから順に表示します（ただし、最初にサーチされるカレントディレクトリおよびソースのディレクトリは省略）。</p>
|
||
<p>さらに、#include 行があると、そのヘッダファイルを include するために <b>mcpp</b> が実際にサーチしたディレクトリが（カレントディレクトリ等も含めて）すべて表示されます。<br>
|
||
#pragma once のあるヘッダファイルを再度 #include した場合は、その旨を表示します。<br>
|
||
また、<b>mcpp</b> は path-list 中の <samp>"foo/../"</samp> といった冗長な部分を削除して正規化しますが、その結果、元の path-list と違った path-list となった場合は、その旨を表示します。<br>
|
||
UNIX 系のシステムでは <b>mcpp</b> は symbolic link は link 先に変換しますが、この場合もその旨を表示します。</p>
|
||
|
||
<h3><a name="3.5.2" href="#toc.3.5.2">3.5.2. #pragma MCPP debug token, #debug token</a></h3>
|
||
<p>まず、読み込んだソース行を表示した上で、<b>mcpp</b> が token を１つ読むたびに、その token と種類を表示します。Token とは正確に言えば preprocessing-token (pp-token) のことです。ソースを読む時ばかりではなく、<b>mcpp</b> がマクロ展開などで内部的に読み返す pp-token も、そのつど（繰り返して）表示されます。</p>
|
||
<p>ただし、1 byte の pp-token のうち次のものは表示されません。これはプログラムのつごうによるものです。</p>
|
||
<ol>
|
||
<li>プリプロセスディレクティブ行の開始の '#'<br>
|
||
<li>function-like
|
||
マクロ定義のパラメータリスト開始の '('<br>
|
||
<li>function-like
|
||
マクロ定義のパラメータを区切る ','<br>
|
||
<li>function-like
|
||
マクロ呼び出しの引数リスト開始の '('<br>
|
||
</ol>
|
||
<p>Pp-token の種類は次の通りです。
|
||
</p>
|
||
<blockquote>
|
||
<table>
|
||
<tr><th>(NAM) </th><td>identifier</td></tr>
|
||
<tr><th>(NUM) </th><td>preprocessing-number</td></tr>
|
||
<tr><th>(OPE) </th><td>operator or punctuator</td></tr>
|
||
<tr><th>(STR) </th><td>string literal</td></tr>
|
||
<tr><th>(WSTR)</th><td>wide string literal</td></tr>
|
||
<tr><th>(CHR) </th><td>character constant</td></tr>
|
||
<tr><th>(WCHR)</th><td>wide character constant</td></tr>
|
||
<tr><th>(SPE) </th><td>$, @ 等の特殊な pp-token</td></tr>
|
||
<tr><th>(SEP) </th><td>token separator (white space)</td></tr>
|
||
</table>
|
||
</blockquote>
|
||
<p>これらのうち (SEP) は改行コード以外は通常は表示されません。
|
||
改行コード等のコントロールコードは <^J>, <^M> 等と表示されます。</p>
|
||
|
||
<h3><a name="3.5.3" href="#toc.3.5.3">3.5.3. #pragma MCPP debug expand, #debug expand</a></h3>
|
||
<p>マクロ呼び出しの展開過程をトレースします。</p>
|
||
<p>Standard モードの #pragma MCPP debug では次の通りです。<br>
|
||
マクロ呼び出しがあると、まずそのマクロの定義が表示されます。さらに、引数が読み込まれ、置換リスト中のパラメータと置き換えられ、再走査されるようすが、逐一表示されます。マクロ定義がネストされていれば、それが順次再走査されて展開されていきます。引数中にマクロがあれば、この過程が再帰的に（パラメータとの置換の前に）トレースされます。</p>
|
||
<p>表示は <b>mcpp</b> 自身のいくつかの関数への出入りのたびに、その関数名とともに行われます。これらの関数は次のような役割をするルーチンです。Standard モードのソースを参照すると、さらによく理解できます。</p>
|
||
<blockquote>
|
||
<table>
|
||
<tr><th>expand_macro</th><td>マクロ展開の入り口ルーチン</td></tr>
|
||
<tr><th>replace </th><td>マクロを１レベル展開する</td></tr>
|
||
<tr><th>collect_args</th><td>引数を集める</td></tr>
|
||
<tr><th>prescan </th><td>置換リストを走査して #, ## 演算子の処理をする</td></tr>
|
||
<tr><th>substitute </th><td>パラメータを引数で置換する</td></tr>
|
||
<tr><th>rescan </th><td>置換リストを再走査する</td></tr>
|
||
</table>
|
||
</blockquote>
|
||
<p>これらのうち、expand_macro 以外は互いに間接再帰の関係にあります。</p>
|
||
<p>replace, collect_args では、<b>mcpp</b> が内部的にスタックに積んでいる展開途中のデータも表示されます。これらのデータでは、<b>mcpp</b> の内部的なコードが次のような記号で表示されます。</p>
|
||
<blockquote>
|
||
<table>
|
||
<tr><th><n> </th><td>n 番目のパラメータ</td></tr>
|
||
<tr><th><TSEP> </th><td>pp-token を区切るために <b>mcpp</b> が挿入した token separator</td></tr>
|
||
<tr><th><MAGIC> </th><td>同名マクロの再置換を禁止するコード</td></tr>
|
||
<tr><th><RT_END></th><td>置換リストの終わりを示すコード</td></tr>
|
||
<tr><th><SRC> </th><td>Identifier がソースファイルから取り込まれたことを示すコード</td></tr>
|
||
</table>
|
||
</blockquote>
|
||
<p>このうち <SRC> は <i>STD</i> モードでだけ使われ、<i>POSTSTD</i> モードでも <i>COMPAT</i> モードでも使われません。</p>
|
||
<p>#pragma MCPP debug token も指定したほうが、わかりやすいでしょう。</p>
|
||
<p>#pragma MCPP debug macro_call または -K オプションも指定した場合は、macro notification がコメントに書き込まれて出力されますが、replace() 以下のルーチンではまだコメントは書き込まれず、何種類かの magic character（内部的なコード）が書き込まれたり削除されたりします。
|
||
これは次のように表示されます。</p>
|
||
<blockquote>
|
||
<table>
|
||
<tr><th><MACm> </th><td>１つのマクロ呼び出しの中に含まれる m 番目のマクロの呼び出し</td></tr>
|
||
<tr><th><MAC_END> </th><td>直前の MACm で始まるマクロ呼び出しの終わり</td></tr>
|
||
<tr><th><MACm:ARGn></th><td>m 番目のマクロの呼び出し中の n 番目の引数</td></tr>
|
||
<tr><th><ARG_END> </th><td>直前の MACm:ARGn で始まる引数の終わり</td></tr>
|
||
</table>
|
||
</blockquote>
|
||
<p>さらに -v オプションも指定した場合は、MAC_END, ARG_END についても開始マーカと同じ番号が symmetrical に表示されます。</p>
|
||
<p>pre-Standard モードの #debug expand では Standard モードとは内部ルーチンが大幅に違っています。説明は略します。</p>
|
||
|
||
<h3><a name="3.5.4" href="#toc.3.5.4">3.5.4. #pragma MCPP debug if, #debug if</a></h3>
|
||
<p>#if, #elif, #ifdef, #ifndef の行を表示し、その評価が真であるか偽であるかを報告します。スキップされる #if section 内では、報告されません。</p>
|
||
|
||
<h3><a name="3.5.5" href="#toc.3.5.5">3.5.5. #pragma MCPP debug expression, #debug expression</a></h3>
|
||
<p>#if, #elif 行の式の評価を詳細にトレースします。</p>
|
||
<p>これは DECUS cpp 自身のデバッグ用にオリジナル版以来あるもので、私はほとんど手を加えていません。内部的な関数名ばかりか、変数名とその値までズラズラと出てきます。<b>mcpp</b> のソースを追いながらでないと、変数は理解できません。<br>
|
||
しかし、複雑な式の値が評価用のスタックに積み降ろしされていくようすは、ソースを見なくても何とか理解できるでしょう。</p>
|
||
|
||
<h3><a name="3.5.6" href="#toc.3.5.6">3.5.6. #pragma MCPP debug getc, #debug getc</a></h3>
|
||
<p><b>mcpp</b> 内の get_ch() という１バイト読み込み関数が呼び出されるたびに、詳細なデータを出力します。ただし、Standard モードでは pp-token をスキャンする時は、その１バイト目しかこのルーチンは呼び出されません。</p>
|
||
<p>#debug getc では token をスキャンする最中もこのルーチンが呼び出されるので、とんでもない量のデータが吐き出されます。<p>
|
||
<p>いずれにしても、膨大なデータが出力されます。使う必要はまずありません。</p>
|
||
|
||
<h3><a name="3.5.7" href="#toc.3.5.7">3.5.7. #pragma MCPP debug memory, #debug memory</a></h3>
|
||
<p>このディレクティブがあると、その時点で <b>mcpp</b> が内部的に使っている malloc(), realloc(), free() によるヒープメモリの状況を１回だけ報告します。これは私の作った kmmalloc や他の何種類かの malloc() を使っている場合だけの機能です（<a href="mcpp-porting.html#4.extra"> mcpp-porting.html#4.extra</a> 参照）。他の malloc() の場合はエラーにはしませんが、何も報告しません。<br>
|
||
このディレクティブが解除されないまま <b>mcpp</b> が終了すると、その時に再度ヒープメモリの状況が報告されます。<b>mcpp</b> が out of memory で終了した場合も同様です。</p>
|
||
|
||
<h3><a name="3.5.8" href="#toc.3.5.8">3.5.8. #pragma MCPP debug macro_call</a></h3>
|
||
<p>Macro notification mode を開始します。
|
||
このモードでは、マクロが定義されるたびに、またマクロが展開されるたびに、そのソース上の行とカラム位置がコメントに埋め込まれて出力されます。
|
||
マクロが引数を持つ場合は、各引数についてもその位置が報告されます。
|
||
ただし、マクロ展開によってトークンが連結された場合は、連結前のトークンに関するマクロ情報は失われます。<br>
|
||
さらに、#undef, #if (#elif, #ifdef, #ifndef), #endif についても、簡単な情報が出力されます。<br>
|
||
このモードは -K オプションで指定することもできます。</p>
|
||
<p>このモードは C/C++ の refactoring tool のために実装されたものです。
|
||
C/C++ にはプリプロセスというフェーズのあることが refactoring tool にとって困難な問題を引き起こしますが、このモードを使えばプリプロセス後の出力からソースを再構成することができるので、tool を作成しやすくなります。*1</p>
|
||
<p>#pragma MCPP debug expand と似ていますが、expand のほうはマクロの展開過程をトレースするためのもので、詳細な情報が出力されるものの、それをコンパイルすることはできません。
|
||
それに対して、macro_call はソース上の正確な位置を伝えるためのもので、情報をコメントに埋め込むので、出力をそのまま再プリプロセスしてコンパイルすることができるのが特徴です。</p>
|
||
<p>注:</p>
|
||
<p>*1 この仕様は主として Taras Glek の提案によるものである。
|
||
彼自身は次のところで mozilla のソースの refactoring に取り組んでいる。</p>
|
||
<p><a href="http://blog.mozilla.com/tglek/"> http://blog.mozilla.com/tglek/</a></p>
|
||
|
||
<h4><a name="3.5.8.1">3.5.8.1. #define に関するコメント</a></h4>
|
||
<p>例えば、ソースの冒頭に次のようなマクロ定義があると、</p>
|
||
<pre>
|
||
#define NULL 0L
|
||
#define BAR(x, y) x ## y
|
||
#define BAZ(a, b) a + b
|
||
</pre>
|
||
<p>次のようなコメントが出力されます。</p>
|
||
<pre>
|
||
/*mNULL 1:9-1:16*/
|
||
/*mBAR 2:9-2:25*/
|
||
/*mBAZ 3:9-3:24*/
|
||
</pre>
|
||
<p>このフォーマットは</p>
|
||
<samp>/*m[NAME] [start line]:[start column]-[end line]:[end column]*/</samp>
|
||
<p>を意味します。
|
||
行とカラムはともに 1 から始まります。
|
||
-K オプションを指定した場合は事前定義マクロも出力されますが、事前定義マクロには位置情報はありません。</p>
|
||
|
||
|
||
<h4><a name="3.5.8.2">3.5.8.2. #undef に関するコメント</a></h4>
|
||
<pre>
|
||
#undef BAZ
|
||
</pre>
|
||
<p>という行では、次のようなコメントが出力されます。</p>
|
||
<pre>
|
||
/*undef 10*//*BAZ*/
|
||
</pre>
|
||
<p>/*undef [lnum]*//*[NAME]*/ というフォーマットで、[lnum] はその行の行番号を、[NAME] はそのマクロ名を示します。</p>
|
||
|
||
<h4><a name="3.5.8.3">3.5.8.3. マクロ展開に関するコメント</a></h4>
|
||
<p>マクロが呼び出されるたびに、それを挟んでその開始と終了を示すマーカが出力されます。
|
||
このマーカのフォーマットは HTML に似たネスト可能なもので、<samp>/*<...*/</samp> がマクロ展開の開始を示し、<samp>/*>*/</samp> がその終了を示します。
|
||
マクロ開始のフォーマットはマクロ定義のフォーマットの <samp>/*m</samp> を <samp>/*<</samp> に変えた次の形をとります。</p>
|
||
<samp>/*<[NAME] [start line]:[start column]-[end line]:[end column]*/</samp>
|
||
<p>マクロが引数をとる場合は、ソース上の引数の位置を示すマーカと、引数の展開の開始と終了を示すマーカも出力されます。
|
||
引数の位置を示すフォーマットは <samp>/*!...*/</samp> という形をしています。
|
||
引数中にマクロがある場合は、再帰的にそのマクロの情報が出力されます。
|
||
ただし、そのマクロがソース上にあったものでなければ、位置情報は出力されません。
|
||
どのマクロの何番目の引数であるかを示すために、引数の id が次の形で示されます。</p>
|
||
<samp>[func-like-macro-name]:[nesting level]-[argument number]</samp>
|
||
<p>これによって <samp>BAZ(BAZ(a,b), c)</samp> といったネストされた同名のマクロとその引数も互いに区別することができます。
|
||
引数の番号は 0 から始まります。
|
||
そして、これに次の形の位置情報が続きます。</p>
|
||
<samp>[start line]:[start column]-[end line]:[end column]</samp>
|
||
<p>また、引数の展開の開始を示すマーカは次の形です。</p>
|
||
<samp>/*<[func-like-macro-name]:[nesting level]-[argument number]*/</samp>
|
||
<p>引数の展開の終了を示すマーカはマクロ展開の終わりのマーカと同じ <samp>/*>*/</mamp> です。</p>
|
||
<p>すなわち、次のソースは</p>
|
||
<pre>
|
||
foo(NULL);
|
||
foo(BAR(some_, var));
|
||
foo = BAZ(NULL, 2);
|
||
bar = BAZ(BAZ(a,b), c);
|
||
</pre>
|
||
<p>次のような結果を出力します。</p>
|
||
<pre>
|
||
foo(/*<NULL 4:5-4:9*/0L/*>*/);
|
||
foo(/*<BAR 5:5-5:20*//*!BAR:0-0 5:9-5:14*//*!BAR:0-1 5:16-5:19*/some_var/*>*/);
|
||
foo = /*<BAZ 6:7-6:19*//*!BAZ:0-0 6:11-6:15*//*!BAZ:0-1 6:17-6:18*//*<BAZ:0-0*//*<NULL 6:11-6:15*/0L/*>*//*>*/ + /*<BAZ:0-1*/2/*>*//*>*/;
|
||
bar = /*<BAZ 7:7-7:23*//*!BAZ:0-0 7:11-7:19*//*!BAZ:0-1 7:21-7:22*//*<BAZ:0-0*//*<BAZ 7:11-7:19*//*!BAZ:1-0*//*!BAZ:1-1*//*<BAZ:1-0*/a/*>*/ + /*<BAZ:1-1*/b/*>*//*>*//*>*/ + /*<BAZ:0-1*/c/*>*//*>*/;
|
||
</pre>
|
||
<p>さらに -v オプションが指定されている時は、マクロ展開の終わりのマーカでも引数の展開の終了を示すマーカでも、開始マーカにあるのと同じマクロ名と引数の id が出力されます。
|
||
すなわち、次のようになります。</p>
|
||
<pre>
|
||
foo(/*<NULL 4:5-4:9*/0L/*NULL>*/);
|
||
foo(/*<BAR 5:5-5:20*//*!BAR:0-0 5:9-5:14*//*!BAR:0-1 5:16-5:19*/some_var/*BAR>*/);
|
||
foo = /*<BAZ 6:7-6:19*//*!BAZ:0-0 6:11-6:15*//*!BAZ:0-1 6:17-6:18*//*<BAZ:0-0*//*<NULL 6:11-6:15*/0L/*NULL>*//*BAZ:0-0>*/ + /*<BAZ:0-1*/2/*BAZ:0-1>*//*BAZ>*/;
|
||
bar = /*<BAZ 7:7-7:23*//*!BAZ:0-0 7:11-7:19*//*!BAZ:0-1 7:21-7:22*//*<BAZ:0-0*//*<BAZ 7:11-7:19*//*!BAZ:1-0*//*!BAZ:1-1*//*<BAZ:1-0*/a/*BAZ:1-0>*/ + /*<BAZ:1-1*/b/*BAZ:1-1>*//*BAZ>*//*BAZ:0-0>*/ + /*<BAZ:0-1*/c/*BAZ:0-1>*//*BAZ>*/;
|
||
</pre>
|
||
<p>この例でもわかるように、マクロ展開終了のマーカも引数展開終了のマーカも、それぞれその前にある最後の同じネストレベルの開始マーカに対応しています。
|
||
したがって、-v オプションを指定しなくても、自動的に対応関係を判断することができます。</p>
|
||
|
||
<h4><a name="3.5.8.4">3.5.8.4. #if (#elif, #ifdef, #ifndef) に関するコメント</a></h4>
|
||
<p>#if (#elif, #ifdef, #ifndef) 行に関しては、その行にあるマクロ等の情報が出力されます。
|
||
例えば、このソースを bar.h とし、</p>
|
||
<pre>
|
||
#define NULL 0L
|
||
#define BAR(x, y) x ## y
|
||
#define BAZ(a, b) a + b
|
||
</pre>
|
||
<p>こちらを foo.c とすると、</p>
|
||
<pre>
|
||
#include "bar.h"
|
||
#ifdef BAR
|
||
#ifndef BAZ
|
||
#if 1 + BAR( 2, 3)
|
||
#endif
|
||
#else
|
||
#if 1
|
||
#endif
|
||
#if BAZ( 1, BAR( 2, 3))
|
||
#undef BAZ
|
||
#endif
|
||
#endif
|
||
#endif
|
||
</pre>
|
||
<p>foo.c は次のような結果を出力します。</p>
|
||
<pre>
|
||
#line 1 "/dir/foo.c"
|
||
#line 1 "/dir/bar.h"
|
||
/*mNULL 1:9-1:16*/
|
||
/*mBAR 2:9-2:25*/
|
||
/*mBAZ 3:9-3:24*/
|
||
#line 2 "/dir/foo.c"
|
||
/*ifdef 2*//*BAR*//*i T*/
|
||
/*ifndef 3*//*BAZ*//*i F*/
|
||
|
||
|
||
/*else 6:T*/
|
||
/*if 7*//*i T*/
|
||
/*endif 8*/
|
||
/*if 9*//*BAZ*//*BAR*//*i T*/
|
||
/*undef 10*//*BAZ*/
|
||
#line 11 "/dir/foo.c"
|
||
/*endif 11*/
|
||
/*endif 12*/
|
||
/*endif 13*/
|
||
</pre>
|
||
<p>すなわち、まず /*if [lnum]*/ というフォーマットで、ディレクティブ名に続いて現在の行番号が表示されます。
|
||
そして、その行にマクロがあれば、それが１つずつ /*[NAME]*/ というフォーマットで表示されます。
|
||
最後に、/*i T*/ または /*i F*/ で、その行の評価が true であるか false であるか、すなわちその #if で始まるブロックがコンパイルされるブロックかスキップされるブロックかが示されます。
|
||
地の文と違って、マクロの展開結果は表示されません。
|
||
<samp>#if 1</samp> のようにマクロのない行については、マクロを表示する /*[NAME]*/ がないだけです。</p>
|
||
<p><samp>#elif, #ifdef, #ifndef</samp> についても同様に /*elif [lnum]*/, /*ifdef [lnum]*/, /*ifndef [lnum]*/ で始まり、マクロが定義されていれば /*[NAME]*/ が続き、/*i T*/ または /*i F*/ で終わります。</p>
|
||
<p>スキップされるブロック中のディレクティブについては何も表示されません。</p>
|
||
|
||
<h4><a name="3.5.8.5">3.5.8.5. #else, #endif に関するコメント</a></h4>
|
||
<p>#else 行では上の例のように、/*else [lnum]:[C]*/ というフォーマットで情報が表示されます。
|
||
[lnum] は行番号、[C] は T または F で、その #else - #endif ブロックがコンパイルされるブロックかそれともスキップされるブロックかを示します。</p>
|
||
<p>#endif 行では上の例のように、/*endif [lnum]*/ というフォーマットで、現在の行番号が表示されます。
|
||
これはもちろん、まだ #endif に対応づけられていない最後の #if (#ifdef, #ifndef) に対応します。</p>
|
||
<p></p>
|
||
|
||
<h4><a name="3.5.8.6">3.5.8.6. #line の出力</a></h4>
|
||
<p>なお、macro notification mode では #line 行のファイル名の出力がデフォルトの場合と違い、#include 行の指定を full-path-list に正規化したものが出力されます（<a href="#3.2">3.2</a> 参照）。
|
||
Refactoring tool の作成を容易にするためです。</p>
|
||
<br>
|
||
|
||
<h2><a name="3.6" href="#toc.3.6">3.6. #assert, #asm, #endasm</a></h2>
|
||
<p>#assert は pre-Standard モードでだけ使えます。GCC 版では実装されません。Standard C の #error に対応する機能です。Standard C で</p>
|
||
<pre>
|
||
#if ULONG_MAX / 2 < LONG_MAX
|
||
#error Bad unsigned long handling.
|
||
#endif
|
||
</pre>
|
||
<p>とするところを</p>
|
||
<pre>
|
||
#assert LONG_MAX <= ULONG_MAX / 2
|
||
</pre>
|
||
<p>と書けます。引数を #if 式として評価し、真（non-zero）であれば何もせず、偽（0）であれば</p>
|
||
<pre>
|
||
Preprocessing assertion failed
|
||
</pre>
|
||
<p>という言葉に続いてその行（行接続とコメント処理をした後の行）を表示します。
|
||
これはエラーとしてカウントしますが、処理は中止しません。</p>
|
||
<p>この
|
||
#assert は System V や GCC の #assert とは、まったく別のものです。</p>
|
||
<p>#asm, #endasm の２つのディレクティブ行ではさまれたブロックはアセンブラソースとして扱われます。pre-Standard モードでだけ使えます。ただし、これは Microware C / 6809 用に書かれたものなので、他の処理系にも移植するには、system.c の do_old(), do_asm(), put_asm() に書き足す必要があります。<br>
|
||
#asm ブロックについては、trigraphs の変換と <backslash><newline> の削除はしますが、コメントの処理や token チェックや文字チェックはせず、行頭の space も削除せず、たまたまマクロと同じ名前があってもマクロ展開せず、ソースの行をそのまま出力します。その他のディレクティブ行は #asm ブロック内では意味を持ちません。</p>
|
||
<p>この #asm, #endasm は Standard C では認められないものです。まず、#pragma sub-directive 以外の拡張ディレクティブが規格外ですが、そればかりか、#pragma asm, #pragma endasm と名前を変えても解決しません。と言うのは、Standard C ではソースはすべてＣの token sequence で成り立っている必要がありますが（厳密に言えば preprocessing token sequence）、アセンブラプログラムはＣの token sequence ではないからです。Standard C でアセンブリコードを使うには、それを文字列リテラルという token に埋め込む方法しかありません。そして、それを処理する組み込み関数をコンパイラ本体に実装して、</p>
|
||
<pre>
|
||
asm(
|
||
" leax _iob+13,y\n"
|
||
" pshs x\n"
|
||
);
|
||
</pre>
|
||
<p>といった形で呼び出すのです。</p>
|
||
<p>やや長いコードだとこんなことはやっていられないので、
|
||
その場合はその部分を別の関数にして、ライブラリ関数を書く時のように、別のファイルでアセンブラプログラムそのものを書いて、アセンブルパスで処理し、それをリンクして使うことになります。これは窮屈な制限のように思えるかもしれませんが、portable なＣプログラムを書くにはアセンブラの部分は完全に分離する必要がありますから、むしろ #asm を使わずに別ファイルで書くようにしたほうが良いでしょう。</p>
|
||
<br>
|
||
|
||
<h2><a name="3.7" href="#toc.3.7">3.7. C99 の新機能（_Pragma() 演算子、可変引数マクロ等）</a></h2>
|
||
<p>これは Standard モードでだけ使えます。<br>
|
||
-V199901L オプションで <tt>__STDC_VERSION__</tt> を 199901L 以上にすると、C99 の次の機能が有効になります。<br>
|
||
C++ でも -V199901L オプションで <tt>__cplusplus</tt> を 199901L 以上にした場合は同様です。1, 7 以外の仕様は C++ Standard にはありませんが、Standard モードでは C99 との互換性を高めるために、このオプションを用意しています。<br>
|
||
ただし、可変引数マクロは Standard モードでは C90 および C++ でも使えるようにしてあります。*1</p>
|
||
<ol>
|
||
<li>// から行末までをコメントとして扱う。<br>
|
||
<li>可変引数マクロが使える。
|
||
<br>
|
||
<li>Preprocessing-number の中に e+, E+, e-, E- と同様に p+, P+, p-, P- という sequence も認める。これは浮動小数点数のビットパターンを 0x1.FFFFFEp+128 というふうに、１６進で表記するためのものである。<br>
|
||
<li>_Pragma() operator が有効になる。<br>
|
||
<li><i>EXPAND_PRAGMA</i> というマクロを <i>TRUE</i> に定義してコンパイルされた <b>mcpp</b> では、#pragma 行の引数は、STDC, MCPP, GCC のどれかで始まるのでない限りマクロ展開の対象となる（デフォルトでは <i>EXPAND_PRAGMA</i> == <i>FALSE</i> であり、マクロ展開しない。展開するのは Visual C, Borland C 版だけである）。<br>
|
||
<li>#if 式は long long のある処理系では long long / unsigned long long で評価する。<br>
|
||
<li>識別子・文字定数・文字列リテラル・pp-number の中にある \unnnn, \Unnnnnnnn の形の UCN という escape sequence を通す。これは Unicode の文字の値を意味する。#if 式では UCN の値は１６進表記として評価する。（ただし、<i>POSTSTD</i> モードでは UCN は使えない）。<br>
|
||
</ol>
|
||
<p>可変引数マクロというのは、次のようなものです。</p>
|
||
<pre>
|
||
#define debug(...) fprintf(stderr, __VA_ARGS__)
|
||
</pre>
|
||
<p>というマクロ定義があると、
|
||
</p>
|
||
<pre>
|
||
debug( "X = %d\n", x);
|
||
</pre>
|
||
<p>というマクロ呼び出しは次のように展開されます。
|
||
</p>
|
||
<pre>
|
||
fprintf(stderr, "X = %d\n", x);
|
||
</pre>
|
||
<p>すなわち、パラメータ・リスト中の <samp>...</samp> が１個以上のパラメータを意味し、置換リスト中の <samp>__VA_ARGS__</samp> がそれに対応します。そして、マクロ呼び出し時には <samp>...</samp> に対応する引数が複数あっても、それらを , を含めて連結したものが一つの引数のように扱われます。</p>
|
||
<p>_Pragma 演算子は _Pragma( "foo bar") と書くと #pragma foo bar と書いたのと同じ効果を持つ演算子です。引数は文字列リテラルまたはワイド文字列リテラル１個でなければなりません。ワイド文字列であれば接頭子 L を削除し、文字列リテラルを囲む " を削除し、文字列リテラルの中の \", \\ をそれぞれ ", \ に置き換えたものが #pragma の引数として扱われます。<br>
|
||
#pragma はソースの論理行１行の初めから終わりまでに書かなければならず、引数が（少なくとも C90 では）マクロ展開されないのに対して、_Pragma() 演算子はソースのどこに書いても独立した論理行に #pragma を書いたのと同じ効果を持ち、マクロの置換リスト中に書くこともでき、マクロ展開の結果として生成された _Pragma() operator も有効です。この柔軟性を利用することで、広い portability を持った pragma directive を書くことができ、処理系による #pragma の違いを１つのヘッダファイルで吸収することもできます。（サンプルとしては "Validation Suite" の pragmas.h, pragmas.t を参照のこと）。*2</p>
|
||
<p>なお、C99 では #if 式の型はその処理系の最大の整数型となっています。long long / unsigned long long は必須とされているので、#if 式の型は long long / unsigned long long またはそれ以上ということになります。C90, C++98 では #if 式は long / unsigned long で評価することになっています。しかし、<b>mcpp</b> は C90, C++98 でも long long / unsigned long long で評価し、long / unsigned long の範囲を超える値に対してはウォーニングを出します。*1</p>
|
||
<p>注:</p>
|
||
<p>*1 これは GCC, Visual C 2005, 2008 等との互換性のためである。他の処理系でも、
|
||
C99 の仕様を一挙に実装するのは難しいので、<tt>__STDC_VERSION__</tt> を 199409L 等としたままこうした一部の仕様から実装してゆくことが予想される。</p>
|
||
<p>*2 C99 では #pragma の引数が STDC で始まる場合はマクロ展開されないが、そうでない場合は implementation-defined である。</p>
|
||
<br>
|
||
|
||
<h2><a name="3.8" href="#toc.3.8">3.8. 処理系ごとの特殊な仕様</a></h2>
|
||
<b>mcpp</b> の compiler-specific-build にはそれぞれの処理系に固有の仕様がいくつか実装されていますが、そのうち実行時オプションでも #pragma でもない特殊なものをこの節で説明します。
|
||
|
||
<h3><a name="3.8.1" href="#toc.3.8.1">3.8.1. GCC, Visual C の可変引数マクロ</a></h3>
|
||
<p>GCC は V.2 のころから <a href="#3.9.1.6">3.9.1.6</a> にあるような独自の仕様の可変引数マクロを持っています。
|
||
これをこのマニュアルでは GCC2 仕様の可変引数マクロと呼びます。
|
||
また GCC V.3 では <a href="#3.9.6.3">3.9.6.3</a> のような新しい仕様が実装されました。
|
||
これをここでは GCC3 仕様の可変引数マクロと呼びます。
|
||
GCC 2.95 では C99 仕様の可変引数マクロも実装されましたが、glibc や Linux のシステムヘッダでは C99 仕様のものはおろか GCC3 仕様のものさえ使われず、いまだに GCC2 仕様が使われています。</p>
|
||
<p>GCC-specific-build の <b>mcpp</b> は V.2.6.3 から <i>STD</i> モードに限って GCC3 仕様の可変引数マクロを実装し、V.2.7 からは GCC2 仕様のものも実装しました。
|
||
これは Linux 等で使う際の不自由を避けるために実装したものです。
|
||
ただし、ウォーニングが出ます。
|
||
GCC 仕様は portability がないだけでなく、文法的に汚いので、新しく書くソースでは使うべきではありません。
|
||
ことに GCC2 仕様がそうです。</p>
|
||
<p>Visual C は 2003 までは可変引数マクロは実装していませんでしたが、2005 で実装されました。
|
||
これは C99 の仕様に GCC3 仕様と似た修正を加えたもので、可変引数が欠如していた場合は、その直前のトークンがコンマであればそれを削除します。
|
||
ただし、GCC と違って '##' という記号は使いません。
|
||
この仕様は Visual C のドキュメントによると、次の例のような結果になります。
|
||
この３番目の例ではコンマは削除しないとされています。
|
||
しかし、Visual C 2005, 2008 は実際にはこのコンマも削除してしまいます。</p>
|
||
<pre>
|
||
#define EMPTY
|
||
#define VC_VA( format, ...) printf( format, __VA_ARGS__)
|
||
VC_VA( "var_args: %s %d\n", "Hello", 2005); /* printf( "var_args: %s %d\n", "Hello", 2005); */
|
||
VC_VA( "absence of var_args:\n"); /* printf( "absence of var_args:\n"); */
|
||
VC_VA( "empty var_args:\n", EMPTY); /* printf( "empty var_args:\n", ); */ /* trailing comma */
|
||
</pre>
|
||
<p><b>mcpp</b> は V.2.7 から Visual C-specific-build の <i>STD</i> モードにこの仕様を実装しました。
|
||
ただし、ウォーニングが出ます。
|
||
上記の３つ目の例ではコンマは削除せず、仕様通りに実装しています。</p>
|
||
|
||
<h3><a name="3.8.2" href="#toc.3.8.2">3.8.2. GCC の 'defined' の処理</a></h3>
|
||
<p>マクロ中に 'defined' というトークンが出てくるケースでは、GCC はそのマクロが #if 行にある場合は、他の場合と異なった恣意的な処理をします。
|
||
この問題については <a href="#3.9.4.6">3.9.4.6</a> で検討しているので、参照してください。</p>
|
||
<p><b>mcpp</b> の GCC-specific-build の <i>STD</i> モードでは V.2.7 から GCC と同じ処理をするようにしました。
|
||
Linux の一部のシステムヘッダなどでこの種の間違ったマクロが使われているのに対処するためです。
|
||
ただし、ウォーニングが出ます。
|
||
自分の書くプログラムでは正しい #if 式を書くようにしてください。</p>
|
||
|
||
<h3><a name="3.8.3" href="#toc.3.8.3">3.8.3. Borland C の asm 文その他の特殊な構文</a></h3>
|
||
<p>Borland C には asm というキーワードがあって、</p>
|
||
<pre>
|
||
asm {
|
||
mov x,4;
|
||
...;
|
||
}
|
||
</pre>
|
||
<p>といった形でアセンブリコードを記述するようになっていますが、これはＣ言語の文法からはずれた極めて変則的なものです。この中にたまたまマクロと同じ名前があると、それはマクロ展開されてしまいます。Borland C そのものでも <b>mcpp</b> でも、その点は同じです。アセンブラプログラムは別の .asm ファイルで書くのが本当でしょう。
|
||
<b>mcpp</b> はこれについては特別な扱いは何もしません。</p>
|
||
<p>Visual C++ にも __asm という同様のキーワードがあります。<br>
|
||
GCC には asm( " mov x,4\n") というまっとうな形の組み込み関数が用意されています。</p>
|
||
|
||
<h3><a name="3.8.4" href="#toc.3.8.4">3.8.4. #import その他</a></h3>
|
||
|
||
<h4>3.8.4.1. Mac OS X / GCC の #import</h4>
|
||
<p>GCC には Objective-C の #import というディレクティブがあり、C/C++ でもこれを #pragma once を暗黙に宣言した #include として使えます。
|
||
Mac OS X の C/C++ ソースには時にこれを使うものがあるようです。</p>
|
||
<p><b>mcpp</b> V.2.7 以降は Mac OS X に限って、GCC 版でもコンパイラ独立版でも、これを実装しています。</p>
|
||
|
||
<h4>3.8.4.2. Visual C の #import, #using</h4>
|
||
<p>Visual C には #import と #using という特殊なディレクティブがあります。
|
||
プリプロセスディレクティブの形をしていますが、内容はコンパイラとリンカに対する指示です。
|
||
#import は GCC のものとは関係ありません。</p>
|
||
<p><b>mcpp</b> の Visual-C-specific-build はこれらの行をそのまま出力します。</p>
|
||
<br>
|
||
|
||
<h2><a name="3.9" href="#toc.3.9">3.9. GCC の問題と GCC との互換性</a></h2>
|
||
<p>GCC 専用版の <b>mcpp</b> では、GCC / cpp (cc1) との互換性を実用上あまり不便がない程度に確保していますが、非互換な面も多々あります。<br>
|
||
まず実行時オプションについては、2 章に見るようにいろいろ違いがあります。-A オプション等は実装していません。また、ディレクティブでは #assert, #ident 等は実装していません。*1<br>
|
||
しかし、幸いなことに、これらのことが原因でコンパイルできないというソースはごく少ないようです。</p>
|
||
<p>むしろ実際に問題となるのは、古いプリプロセッサの特殊な仕様をあてにしたソースです。これらの多くは GCC で -pedantic を指定するとウォーニングが出ます。<b>mcpp</b> は Standard モードのものではエラーチェックを規格通りに実装しているので、ほぼ GCC の -pedantic がデフォルトとなっています。GCC はデフォルトではそうした規格違反ソースを黙って通すため、それをあてにしたソースが一部に見られます。そうしたソースを規格に合致するように書くのはきわめて簡単なことで、わざわざ規格違反の書き方をする必然性は何もありません。単に移植性を損なうだけで、悪くするとバグの温床となるので、見つけしだい直しておきましょう。*2</p>
|
||
<p>注:</p>
|
||
<p>*1 これらはいずれも必要なら #pragma で実装すべきものである。
|
||
#include_next, #warning も同様であるが、GCC のシステムでは実際に時々使われているので、<b>mcpp</b> でも GCC 版に限って実装した。ただし、ウォーニングの対象になる。</p>
|
||
<p>*2 3.9 から 3.9.3 は 1998 年に書かれたものであるが、その後は状況が変わってきている。
|
||
古い仕様に依存するソースは少なくなり、それに代わって GCC 独自の拡張機能や実装の細部に依存するものが増えてきている。
|
||
3.9.4 以降、ことに 3.9.8 以降で取り上げるのは主としてそうした問題である。
|
||
(2008/03)</p>
|
||
|
||
<h3><a name="3.9.1" href="#toc.3.9.1">3.9.1. FreeBSD 2 / kernel ソースのプリプロセス</a></h3>
|
||
<p>以下に、FreeBSD 2.2.2-R (1997/05) の kernel ソースを例に問題点を挙げておきます。ディレクトリ名はいずれも /sys (/usr/src/sys) 中のものです。これらのうち 7, 8 は必ずしも規格違反ではなく、<b>mcpp</b> でも期待通りの処理をします。しかし、あぶなっかしい書き方なのでウォーニングが出ます。6 は拡張機能で、C99 でも同じ機能が用意されていますが、GCC / cpp とは記法が異なります。</p>
|
||
|
||
<h4>3.9.1.1. 行をまたぐ文字列リテラル</h4>
|
||
<p><samp>i386/apm/apm.c, i386/isa/npx.c, i386/isa/seagate.c, i386/scsi/aic7xxx.h, dev/aic7xxx/aic7xxx_asm.c, dev/aic7xxx/symbol.c, gnu/ext2fs/i386-bitops.h, pc98/pc98/npx.c</samp> にはこういう書き方でアセンブラソースが埋め込まれています。</p>
|
||
<pre>
|
||
asm("
|
||
asm code0
|
||
#ifdef PC98
|
||
asm code1
|
||
#else
|
||
asm code2
|
||
#endif
|
||
...
|
||
");
|
||
</pre>
|
||
<p>文字列リテラルを閉じる " が行末までになかった場合は行末で閉じられていると解釈するのが GCC / cpp のデフォルトの仕様ですが、それを使っているのです（さらにコンパイラ本体では asm() の中身全体が行をまたぐ文字列リテラルと解釈されるらしい）。</p>
|
||
<p>アセンブラソースは .s ファイルとして切り離しておくのが良いスタイルだと思われますが、どうしても .c ファイルに埋め込みたければ、こんなあぶなっかしいことをしなくても、次のようにすればすみます。これであれば Standard C 準拠のプリプロセッサでも問題ありません。</p>
|
||
<pre>
|
||
asm(
|
||
" asm code0\n"
|
||
#ifdef PC98
|
||
" asm code1\n"
|
||
#else
|
||
" asm code2\n"
|
||
#endif
|
||
" ...\n"
|
||
);
|
||
</pre>
|
||
|
||
<h4>3.9.1.2. #else junk, #endif junk</h4>
|
||
<p><samp>ddb/db_run.c, netatalk/at.h, netatalk/aarp.c, net/if-ethersubr.c, i386/isa/isa.h, i386/isa/wdreg.h, i386/isa/tw.c, i386/isa/b004.c, i386/isa/matcd/matcd.c, i386/isa/sound/sound_calls.h, i386/isa/pcvt/pcvt_drv.c, pci/meteor.c, pc98/pc98/pc98.h</samp> にはこういう行があります。</p>
|
||
<pre>
|
||
#endif MACRO
|
||
</pre>
|
||
<p>これはこうしておきましょう。</p>
|
||
<pre>
|
||
#endif /* MACRO */
|
||
</pre>
|
||
|
||
<h4>3.9.1.3. #ifdef 0</h4>
|
||
<p><samp>i386/apm/apm.c</samp> にはなんと</p>
|
||
<pre>
|
||
#ifdef 0
|
||
</pre>
|
||
<p>という奇怪な行があります。
|
||
</p>
|
||
<p>もちろん、
|
||
</p>
|
||
<pre>
|
||
#if 0
|
||
</pre>
|
||
<p>の間違いです。実際には使われていない、
|
||
デバッグもされていないソースなのでしょう。</p>
|
||
|
||
<h4>3.9.1.4. マクロの二重定義</h4>
|
||
<p><samp>gnu/i386/isa/dgb.c</samp> では次の行が何かのヘッダファイルと矛盾する二重定義になります。</p>
|
||
<pre>
|
||
#define DEBUG
|
||
</pre>
|
||
<p>Standard C では二重定義は violation of constraint で、実際には処理系によって、エラーにした上で初めの定義を有効とするものと、GCC 2 / cpp のようにデフォルトでは黙ってあとの定義を有効とするものとあります。確実にあとの定義を有効にするには、直前に</p>
|
||
<pre>
|
||
#undef DEBUG
|
||
</pre>
|
||
<p>を入れるべきです。</p>
|
||
|
||
<h4>3.9.1.5. #warning</h4>
|
||
<p><samp>i386/isa/if_ze.c, i386/isa/if_zp.c</samp> には #warning があります。Kernel ソース中で唯一の規格違反ディレクティブです。Standard C に合わせるためには、この行をコメントアウトするしかありません。</p>
|
||
<p><b>mcpp</b> の GCC 版では #warning が使えるので、このまま通ります。</p>
|
||
|
||
<h4><a name="3.9.1.6">3.9.1.6. 可変引数マクロ</a></h4>
|
||
<p><samp>gnu/ext2fs/ext2_fs.h, i386/isa/mcd.c</samp> には次のような可変個引数のマクロが定義されています。</p>
|
||
<pre>
|
||
#define MCD_TRACE(fmt, a...) \
|
||
{ \
|
||
if (mcd_data[unit].debug) { \
|
||
printf("mcd%d: status=0x%02x: ", \
|
||
unit, mcd_data[unit].status); \
|
||
printf(fmt, ## a); \
|
||
} \
|
||
}
|
||
|
||
# define ext2_debug(fmt, a...) { \
|
||
printf ("EXT2-fs DEBUG (%s, %d): %s:", \
|
||
__FILE__, __LINE__, __FUNCTION__); \
|
||
printf (fmt, ## a); \
|
||
}
|
||
</pre>
|
||
<p>これは GCC / cpp 独自の拡張仕様で、他の処理系では通用しません。この ## a のところは単に a とする書き方もあります。## があると、マクロ呼び出しで <samp>a...<samp> に対応する引数がなかった場合は、その直前のコンマを削除します。<br>
|
||
C99 では可変個引数マクロが追加されていますが、記法が異なり、これらの例は次のように書くことになります。</p>
|
||
<pre>
|
||
#define MCD_TRACE( ...) \
|
||
{ \
|
||
if (mcd_data[unit].debug) { \
|
||
printf("mcd%d: status=0x%02x: ", \
|
||
unit, mcd_data[unit].status); \
|
||
printf( __VA_ARGS__); \
|
||
} \
|
||
}
|
||
|
||
# define ext2_debug( ...) { \
|
||
printf ("EXT2-fs DEBUG (%s, %d): %s:", \
|
||
__FILE__, __LINE__, __FUNCTION__); \
|
||
printf ( __VA_ARGS__); \
|
||
}
|
||
</pre>
|
||
<p>C99 では <samp>...</samp> に対応する呼び出し時の引数は１個以上必要なのに対して、GCC / cpp では <samp>a...</samp> に対応する引数は０個でもかまわないというのが、やっかいな相違点です。<b>mcpp</b> ではこれに対処するため、<samp>...</samp> に対応する引数が１個もない場合は、warning は出すもののエラーにはしないようにしています。したがって、次のような書き方もできます。このほうが書き換えは一対一対応でできるので、簡単です。しかし、この書き方では、カラ引数の直前のコンマが残るので、たとえば printf( fmt, ) 等という展開結果になってしまうことがあります。その場合は、マクロ定義を上記の C99 仕様の書き方にするか、またはマクロ呼び出しでカラ引数を使わないようにするしかありません。カラ引数の代わりには NULL や 0 のような無害なトークンを使って、<samp>MCD_TRACE(fmt, NULL)</samp> 等と書くことになります。*1</p>
|
||
<pre>
|
||
#define MCD_TRACE(fmt, ...)
|
||
{
|
||
if (mcd_data[unit].debug) {
|
||
printf("mcd%d: status=0x%02x: ",
|
||
unit, mcd_data[unit].status);
|
||
printf(fmt, __VA_ARGS__);
|
||
}
|
||
}
|
||
|
||
# define ext2_debug(fmt, ...) {
|
||
printf ("EXT2-fs DEBUG (%s, %d): %s:",
|
||
__FILE__, __LINE__, __FUNCTION__);
|
||
printf (fmt, __VA_ARGS__);
|
||
}
|
||
</pre>
|
||
<p>注:</p>
|
||
<p>*1 GCC 2.95.3 以降では C99 の構文の可変引数マクロも実装されているので、こちらを使うほうが良い。GCC の可変引数マクロは引数がゼロ個でも良いという柔軟性があるが、その記法は良くない。<samp>args...</samp> というパラメータでは <samp>args</samp> と <samp>...</samp> とはくっついていなければならないが、こういう pp-token は存在しない。置換リストでトークン連結演算子と同じ記法を別の用途に使っているのも、感心しない。C99 の記法で、ゼロ個の可変引数も許容するという仕様が妥当であろう。<br>
|
||
なお、GCC 3 では可変引数マクロについて、GCC 2 以来の仕様と C99 の仕様との折衷的な書き方が追加された。それについては <a href="#3.9.6.3">3.9.6.3</a> を参照のこと。</p>
|
||
|
||
<h4>3.9.1.7. マクロ呼び出しのカラ引数</h4>
|
||
<p><samp>nfs/nfs.h, nfs/nfsmount.h, nfs/nfsmode.h, netinet/if_ether.c, netinet/in.c, sys/proc.h, sys/socketvars.h, i386/scsi/aic7xxx.h, i386/include/pmap.h, dev/aic7xxx/scan.l, dev/aic7xxx/aic7xxx_asm.c, kern/vfs_cache.c, pci/wd82371.c, vm/vm_object.h, vm/device/pager.c</samp> にはこういうマクロ呼び出しがあります。<samp>/usr/include/nfs/nfs.h</samp> でも同様です。</p>
|
||
<pre>
|
||
LIST_HEAD(, arg2)
|
||
TAILQ_HEAD(, arg2)
|
||
CIRCLEQ_HEAD(, arg2)
|
||
SLIST_HEAD(, arg2)
|
||
STAILQ_HAED(, arg2)
|
||
</pre>
|
||
<p>第一引数がカラなのです。カラ引数は C99 では公認されましたが、C90 では undefined です。ネストされたマクロ呼び出しでたまたま引数がカラになった場合のこと等を考えると、カラ引数が規定されているほうが良いと言えますが、ソース中にカラ引数を書くことにはこれらの場合は必然性がなく、感心しません。引数が１つのマクロではカラ引数と引数の欠落との区別がつかないという syntax のあいまいさがあることも、忘れてはなりません。</p>
|
||
<p>こう書くほうが良いでしょう。これであれば Standard C 準拠のどのプリプロセッサでも問題ありません。</p>
|
||
<pre>
|
||
#define EMPTY
|
||
|
||
LIST_HEAD(EMPTY, arg2)
|
||
TAILQ_HEAD(EMPTY, arg2)
|
||
CIRCLEQ_HEAD(EMPTY, arg2)
|
||
SLIST_HEAD(EMPTY, arg2)
|
||
STAILQ_HAED(EMPTY, arg2)
|
||
</pre>
|
||
<p>ところで、これらのヘッダファイルの中には、これらのマクロの定義もなければ他のどのヘッダも #include されていないというものがあります（nfs ディレクトリのもの）。これらのマクロの定義は sys/queue.h にあり、*.c プログラムがそちらを先に #include することを期待しているのです。あぶなっかしい書き方のヘッダ群です。</p>
|
||
<p>なお、<samp>kern/kern_mib.c</samp> には次のようなマクロ呼び出しがあります。</p>
|
||
<pre>
|
||
SYSCTL_NODE(, arg2, arg3, arg4, arg5, arg6, arg7, arg8, arg9)
|
||
</pre>
|
||
<p>しかし、このカラ引数は <tt>EMPTY</tt> とするわけにはいきません。このマクロの定義は <samp>sys/sysctl.h</samp> にあり、次のようになっているからです。</p>
|
||
<pre>
|
||
#define SYSCTL_NODE(parent, nbr, name, access, handler, descr)
|
||
extern struct linker_set sysctl_##parent##_##name;
|
||
SYSCTL_OID(parent, nbr, name, CTLTYPE_NODE|access,
|
||
(void*)&sysctl_##parent##_##name, 0, handler, "N", descr);
|
||
TEXT_SET(sysctl_##parent##_##name, sysctl__##parent##_##name);
|
||
</pre>
|
||
<p>すなわち、これらの引数はマクロ展開されないのです（この中にある <tt>SYSCTL_OID</tt> というマクロでも、やはり第一引数等はマクロ展開されない）。これはカラ引数のままにしておくしかありません。*1</p>
|
||
<p>注:</p>
|
||
<p>*1 C99 ではカラ引数は合法とされている。また、この <tt>SYSCTL_NODE</tt>(), <tt>SYSCTL_OID</tt>() のようなマクロのことを考えると、<tt>EMPTY</tt> というマクロを使う方法は万能ではないので、カラ引数のままにしておくのも一理あることである。<tt>EMPTY</tt> を使っても、マクロ呼び出しがネストされていると、やはりカラ引数が発生してしまうという問題もある。しかし、ソースの readability を考えると、<tt>EMPTY</tt> を使えるところでは使ったほうが良いように思われる。</p>
|
||
|
||
<h4>3.9.1.8. Function-like マクロの名前に置換される object-like マクロ</h4>
|
||
<p><samp>i386/include/endian.h</samp> にはこういうマクロ定義があります。<samp>/usr/include/machine/endian.h</samp> でも同様です（同種の定義が４つある）。</p>
|
||
<pre>
|
||
#define __byte_swap_long(x) (replacement text)
|
||
#define NTOHL(x) (x) = ntohl((u_long)x)
|
||
#define ntohl __byte_swap_long
|
||
</pre>
|
||
<p>問題は ntohl の定義です。これは object-like マクロでありながら function-like マクロの名前に展開され、そのため再走査で続くテキストを巻き込み、あたかも function-like マクロのように展開されます。この展開方法は K&R 1st. 以来の暗黙の仕様で、Standard C ではなぜか合法となったものです。しかし、私が別のところで論じているように、この仕様こそがマクロ展開を無用に複雑にし、規格書にまで混乱をもたらしている元凶であり、「バグのような仕様」なのです。*1</p>
|
||
<p>この例は実態は function-like マクロであるものを省略して object-like マクロとして書いているものですが、function-like マクロらしく次のように書いたほうが良いでしょう。これであれば何の問題もありません。</p>
|
||
<pre>
|
||
#define ntohl(x) __byte_swap_long(x)
|
||
</pre>
|
||
<p><samp>i386/isa/sound/os.h</samp> にも同種のマクロ定義があります。</p>
|
||
<pre>
|
||
#define INB inb
|
||
#define INW inb
|
||
</pre>
|
||
<p>これはこうしておきましょう。
|
||
</p>
|
||
<pre>
|
||
#define INB(x) inb(x)
|
||
#define INW(x) inb(x)
|
||
</pre>
|
||
<p>注:</p>
|
||
<p>*1 ISO 9899:1990 の Corrigendum 1:1994 ではこうした例は undefined とされた。そして、C99 では Corrigendum のこの項は別のものと置き換えられた。しかし、規格書はこれに関しては混乱している。詳細は <a href="cpp-test.html#2.7.6"> cpp-test.html#2.7.6</a> を参照。</p>
|
||
|
||
<h4>3.9.1.9. .S ファイルの「プリプロセス」</h4>
|
||
<p>Kernel ソースには何本かの .S ファイル、すなわちアセンブラソースがあります。ところがこれらには #include や #ifdef があって、「プリプロセス」が必要なのです。FreeBSD 2.2.2-R ではこれらのソースは cc を -x assembler-with-cpp オプションを付けて呼び出すという方法で処理しています。そうすると cc は /usr/libexec/cpp を -lang-asm オプションをつけて呼び出し、さらに as を呼び出します。</p>
|
||
<p>こういう .S ファイルはもちろん規格外の変則ソースです。これが意図通りに「プリプロセス」されるためには、マクロとたまたま一致する「名前」がアセンブラソースに含まれていてはいけません。そして、「プリプロセス」では、「トークン」間の white space の有無はそのまま保存されなければならず、行頭の space も削除せずに保存されなければなりません。行の最初の「トークン」がアセンブラのコメントである # である場合はプリプロセッサの側で特殊な処理が必要です。使えるプリプロセッサがかなり制限され、バグの混入にも余計な神経を使わなければならないので、決して良いことだとは思えません。*1</p>
|
||
<p>複数のマシンに対応させる等のためにプリプロセスする必要があるのであれば、.S ファイルではなく .c ファイルとして、次の形で書くのが良いでしょう。4.4BSD-Lite では実際にこの書き方になっています。</p>
|
||
<pre>
|
||
asm(
|
||
" asm code0\n"
|
||
#ifdef Machine_A
|
||
" asm code1\n"
|
||
#else
|
||
" asm code2\n"
|
||
#endif
|
||
" ...\n"
|
||
);
|
||
</pre>
|
||
<p>注:</p>
|
||
<p>*1 FreeBSD 2.0-R ではこれらのファイル名は *.S ではなく *.s となっていて、Makefile ではその処理には cc ではなく cpp を呼び出して、次に as を呼び出すようになっていた。そして、cpp を呼び出すと /usr/bin/cpp が動くが、これは shell-script で、/usr/libexec/cpp -traditional を呼び出す。このほうが、script を書き換えることで使うプリプロセッサを変えることができるので、便利であった。</p>
|
||
|
||
<h3><a name="3.9.2" href="#toc.3.9.2">3.9.2. FreeBSD 2 / libc ソースのプリプロセス</a></h3>
|
||
<p>FreeBSD 2.2.2R の <samp>/usr/src/lib/libc</samp> の全ソースもコンパイルしてみましたが、特に問題はありませんでした。大半は 4.4BSD-Lite からそのまま来ているからでしょうか。これだけの規模できれいなソースがそろっているのは珍しいことで、特筆に値します。</p>
|
||
<p>ただ１個所、<samp>gen/getgrent.c</samp> に次のような行が見つかりました。もちろん、行末の ; は余計です。</p>
|
||
<pre>
|
||
#endif;
|
||
</pre>
|
||
|
||
<h3><a name="3.9.3" href="#toc.3.9.3">3.9.3. GCC 2 / cpp の仕様の問題</a></h3>
|
||
<p>さて、以上に見たように、これらのソースを規格に合致した、より移植性の高い、より安全なスタイルで書くことには、何の面倒もデメリットもありません。にもかかわらず、なぜこうしたソースがいまだに書かれているのでしょうか？</p>
|
||
<p>FreeBSD 2.0-R と 2.2.2-R の kernel ソースを比べても、この種のものはあまり減っていません。新しいほど規格合致性が高くなっているとは限らないところが問題なのです。この種のあやしげなスタイルのソースは 4.4BSD-Lite から存在しているものはわずかです。4.4BSD は Standard C と POSIX に準拠して書き直されたからでしょう。ところが、FreeBSD への実装で一部のソースにこうした古いスタイルが復活してしまったのです。上記の ntohl のように 4.4BSD-Lite では ntohl(x) の形になっているものが FreeBSD ではわざわざ ntohl の形に書き替えられているものさえあります。いったん一掃されたものが、なぜ復活するのでしょうか？</p>
|
||
<p>私はここには、GCC / cpp がこれらを黙って通してしまうことの悪影響が現れていると思います。-pedantic の動作がデフォルトであれば、こうしたスタイルのソースがわざわざ「新しく」書かれることはなかったでしょう。かつては -pedantic-errors をデフォルトにしたのではコンパイルできないソースが多くて、実用的ではなかったのかもしれません。gcc の man page には -pedantic オプションについて、「これを使う理由は何もない。このオプションの存在理由は pedants を満足させることだけである」とあります(*1)。しかし Standard C が決まって８年もたついまとなっては、-pedantic-errors とまではいかなくても -pedantic をデフォルトにすべき時に来ていると思われます。</p>
|
||
<p>FreeBSD 2.0-R ではコメントのネストが時々見られましたが、2.2.2-R では一掃されています。一掃されたのは、GCC / cpp が認めなくなったからです。これは -pedantic とは関係ありませんが、プリプロセッサのソースチェックの威力はそれほど大きいのです。</p>
|
||
<p>注:</p>
|
||
<p>*1 この 3.9.3 が書かれたのは 1998 のことである。その後、gcc の man や info では、さすがにこの表現は削除された。しかし、仕様が特に変わったわけではない。</p>
|
||
|
||
<h3><a name="3.9.4" href="#toc.3.9.4">3.9.4. Linux / glibc 2.1 ソースのプリプロセス</a></h3>
|
||
<p>glibc (GNU LIBC) 2.1.3 (2000/02) のソースをコンパイルしてみました。これには FreeBSD の libc とは違ってかなり多くの問題があります。中には GCC / cpp の undocumented な仕様を利用しているものさえあり、その仕様を突き止めるだけでかなりの時間を費やしてしまったことが何回かありました。</p>
|
||
|
||
<h4>3.9.4.1. 行をまたぐ文字列リテラル</h4>
|
||
<p><samp>sysdeps/i386/dl-machine.h, stdlib/longlong.h</samp> には</p>
|
||
<pre>
|
||
#define MACRO asm("
|
||
instr 0
|
||
instr 1
|
||
instr 2
|
||
")
|
||
</pre>
|
||
<p>といった形の行をまたぐ文字列リテラルがいくつもあります。
|
||
中にはかなり長大なものもあります。</p>
|
||
<p>また、make によって生成される <samp>compile/csu/version-info.h</samp> にも行をまたぐ文字列リテラルが現れます。<br>
|
||
これはもちろん規格違反のソースですが、GCC ではこれを改行コードの入った文字列リテラルとして扱います。<br>
|
||
<b>mcpp</b> では -lang-asm (-x assembler-with-cpp, -a) オプションを指定すると、こうした行をまたぐ文字列リテラルを</p>
|
||
<pre>
|
||
#define MACRO asm("\n instr 0\n instr 1\n instr 2\n")
|
||
</pre>
|
||
<p>という形に変換して処理します（3.9.1.1 のように途中にディレクティブのはさまっているものは、これでは対応できず、ソースを書き直すしかない）。</p>
|
||
|
||
<h4>3.9.4.2. #include_next, #warning</h4>
|
||
<p><samp>catgets/config.h, db2/config.h, include/fpu_control.h, include/limits.h, include/bits/ipc.h, include/sys/sysinfo.h, locale/programs/config.h, sysdeps/unix/sysv/linux/a.out.h</samp> には #include_next が現れます。</p>
|
||
<p>また、<samp>sysvipc/sys/ipc.h</samp> には #warning があります。</p>
|
||
<p>これらは規格では認められていないディレクティブですが、glibc 2 のシステムではことに #include_next は不可欠のものとなってしまっているので、<b>mcpp</b> でも GCC 用では #include_next と #warning は実装しています。</p>
|
||
<p>#include_next の問題は規格違反だということだけではありません。Include directories とそのサーチ順は環境変数等のユーザ側の設定によって変わる場合があるので、それによって結果が違ってくる危険があります。</p>
|
||
<p>Glibc の include ディレクトリのファイルには、glibc を install すると /usr/include ディレクトリにコピーされるものもあります。すなわち、システムのヘッダファイルとして使われるものなのです。こうしたヘッダファイルに#include_next が使われていることは、システムヘッダがかなりつぎはぎ状態になってきていることを表しています。大整理が必要な時期にきているようです。</p>
|
||
|
||
<h4>3.9.4.3. 可変引数マクロ</h4>
|
||
<p><samp>elf/dl-lookup.c, elf/dl-version.c, elf/ldsodefs.h, glibc-compat/nss_db/db-XXX.c, glibc-compat/nss_files/files-XXX.c, linuxthreads/internals.h, locale/loadlocale.c, locale/programs/linereader.h, locale/programs/locale.c, nss/nss_db/db-XXX.c, nss/nss_files/files-XXX.c, sysdeps/unix/sysdep.h, sysdeps/unix/sysv/linux/i386/sysdep.h, sysdeps/i386/fpu/bits/mathinline.h</samp></p>
|
||
<p>以上のファイルには GCC / cpp の仕様の可変個引数マクロの定義と呼び出しがあります。*1</p>
|
||
|
||
<p>注:</p>
|
||
<p>*1 これは GCC2 からある仕様であるが、そのほか GCC3 では C99 と GCC2 との折衷的な仕様が追加された。
|
||
それについては <a href="#3.9.6.3">3.9.6.3</a> を参照のこと。</p>
|
||
|
||
<h4>3.9.4.4. マクロ呼び出しのカラ引数</h4>
|
||
<p><samp>catgets/catgetsinfo.h, elf/dl-open.c, grp/fgetgrent_r.c, libio/clearerr_u.c, libio/rewind.c, libio/clearerr.c, libio/iosetbuffer.c, locale/programs/ld-ctype.c, locale/setlocale.c, login/getutent_r.c, malloc/thread-m.h, math/bits/mathcalls.h, misc/efgcvt_r.c, nss/nss_files/files-rpc.c, nss/nss_files/files-network.c, nss/nss_files/files-hosts.c, nss/nss_files/files-proto.c, pwd/fgetpwent_r.c, shadow/sgetspent_r.c, sysdeps/unix/sysv/linux/bits/sigset.h, sysdeps/unix/dirstream.h</samp></p>
|
||
<p>以上のファイルにはマクロ呼び出しのカラ引数が現れます。ことに <samp>math/bits/mathcalls.h</samp> にはカラ引数が 79 個もあります。このヘッダファイルは <samp>/usr/include/bits/mathcalls.h</samp> に install されて、<samp>/usr/include/math.h</samp> から #include されるものです。<tt>EMPTY</tt> というマクロを使っても、マクロ呼び出しがネストされているので、やはり大量のカラ引数が発生します。もっときれいなマクロの書き方はできないものでしょうか。</p>
|
||
|
||
<h4>3.9.4.5. Function-like マクロの名前に置換される object-like マクロ</h4>
|
||
<p><samp>argp/argp-fmtstream.h, ctype/ctype.h, elf/sprof.c, elf/dl-runtime.c, elf/do-rel.h, elf/do-lookup.h, elf/dl-addr.c, io/ftw.c, io/ftw64.c, io/sys/stat.h, locale/programs/ld-ctype.c, malloc/mcheck.c, math/test-*.c, nss/nss_files/files-*.c, posix/regex.c, posix/getopt.c, stdlib/gmp-impl.h, string/bits/string2.h, string/strcoll.c, sysdeps/i386/i486/bits/string.h, sysdeps/generic/_G_config.h, sysdeps/unix/sysv/linux/_G_config.h</samp></p>
|
||
<p>以上のファイルには function-like マクロの名前に置換される object-like マクロの定義があります。中には、math/test-*.c にあるもののように、function-like マクロが object-like マクロに置換されて、さらにそれが function-like マクロの名前に置換されるものもあります。そういう書き方をする必然性があるのでしょうか？</p>
|
||
|
||
<h4><a name="3.9.4.6">3.9.4.6. 'defined' に展開されるマクロ</a></h4>
|
||
<p><samp>sysdeps/generic/_G_config.h, sysdeps/unix/sysv/linux/_G_config.h, malloc/malloc.c</samp> には、例えば次のように defined という pp-token に展開されるマクロ定義があります。</p>
|
||
<pre>
|
||
#define HAVE_MREMAP defined(__linux__) && !defined(__arm__)
|
||
</pre>
|
||
<p>これは、</p>
|
||
<pre>
|
||
#if HAVE_MREMAP
|
||
</pre>
|
||
<p>というディレクティブがあると</p>
|
||
<pre>
|
||
#if defined(__linux__) && !defined(__arm__)
|
||
</pre>
|
||
<p>となることを期待しているものです。
|
||
</p>
|
||
<p>しかし、まず #if 行中でマクロ展開の結果に defined という pp-token が出てくるのは、規格では undefined です。そのことは別としても、なおこのマクロは変です。</p>
|
||
<p><tt>HAVE_MREMAP</tt> というマクロはいったん</p>
|
||
<pre>
|
||
defined(__linux__) && !defined(__arm__) (1)
|
||
</pre>
|
||
<p>と置換され、次に identifier である defined, __linux__, __arm__ がそれぞれマクロであるかどうかが調べられ、マクロであれば展開されます。したがって、defined はマクロとして定義されているはずはないので（もし定義されていれば、それ自体がすでに undefined）、仮に __linux__ が 1 に定義されていて、__arm__ が定義されていなければ、このマクロは最終的に次のように展開されます。</p>
|
||
<pre>
|
||
defined(1) && !defined(__arm__)
|
||
</pre>
|
||
<p>defined(1) はもちろん #if 式の syntax error です。</p>
|
||
<p>ところが GCC では、#if 行でなければこうなるのですが、#if 行に限って (1) でマクロ展開をやめてしまい、これを #if 式として評価します。Undefined であるのでそれも間違いとは言えませんが、マクロ展開が #if 行とそうでない場合とで異なるのは、一貫しない仕様です。少なくともその仕様には portability がありません。*1</p>
|
||
<p>問題のマクロは次のように書けば、何も問題ないのです。</p>
|
||
<pre>
|
||
#if defined(__linux__) && !defined(__arm__)
|
||
#define HAVE_MREMAP 1
|
||
#endif
|
||
</pre>
|
||
<p>こういう危なっかしいソースは早く一掃されてほしいものです。
|
||
*2</p>
|
||
<p>注:</p>
|
||
<p>*1 GCC 2 / cpp は #if 行では内部的に defined を特殊なマクロとして扱っている。
|
||
そのため、次のようなトークン列をマクロ展開のために再走査するのであるが、その結果がこれをマクロ展開せずに、#if 式として評価することになるのである。すなわち、マクロ展開と #if 式の評価とが分離せずに混交しているのである。</p>
|
||
<blockquote>
|
||
<samp>defined(__linux__) && !defined(__arm__)</samp>
|
||
</blockquote>
|
||
<p>これは GCC / cpp のプログラム構造にもかかわる問題である。GCC 2 / cpp では rescan() というマクロ再走査ルーチンが事実上のメインルーチンとなっていて、これがソーステキストを初めから終わりまで読みながら処理してゆく。そして、プリプロセスディレクティブの処理ルーチンもこの中から呼び出されるのである。何でもマクロで実装するのはマクロプロセッサの伝統的なプログラム構造であるが、この構造が、マクロ展開と他の処理との混交を引き起こす背景になっていると考えられる。</p>
|
||
<p>*2 glibc 2.4 ではこのマクロは直されている。
|
||
ところが、他のマクロで同種のものが新たにいくつも出てきている。</p>
|
||
|
||
<h4>3.9.4.7. .S ファイルの「プリプロセス」</h4>
|
||
<p>*.S という名前のファイルはプリプロセスを要するアセンブラのソースですが、その中には #include, #define, #if 等のプリプロセスディレクティブが出てきます。さらに、Make によって生成される <samp>compile/csu/crti.S</samp> というファイルには、</p>
|
||
<pre>
|
||
#APP
|
||
</pre>
|
||
<p>とか</p>
|
||
<pre>
|
||
#NO_APP
|
||
</pre>
|
||
<p>という行まで現れます。
|
||
これらの行は無効なプリプロセスディレクティブと構文上、区別がつきません。GNU ではこれらの行はそのままプリプロセス後に残って、アセンブラのコメントとして扱われるようです。</p>
|
||
<p>また、## 演算子による pp-token の連結が invalid な pp-token を生成してしまうソースもあります。GCC / cpp はこれを黙ってそのまま出力します。</p>
|
||
<p><b>mcpp</b> では GCC / cpp との互換性のためにやむなく、-lang-asm (-x assembler-with-cpp, -a) オプションを付けると、こうした illegal なディレクティブや ## によって生成された invalid な pp-token をエラーにせず、ウォーニングを出すもののそのまま出力するようにしました。</p>
|
||
<p>こうしたソースは本来、アセンブラ用のマクロプロセッサで処理すべきものだと思われます。GNU にも gasp というアセンブラ用マクロプロセッサがあるようですが、なぜかほとんど使われていないようです。</p>
|
||
|
||
<h4><a name="3.9.4.8">3.9.4.8. rpcgen と -dM オプションの仕様の問題</a></h4>
|
||
<p>GCC は -dM というオプションで起動するとマクロ定義だけを出力しますが、make check で使われる <samp>stdlib/isomac.c</samp> はこれを利用しています。isomac.c の問題は、マクロ定義ファイルの形式として GCC の出力形式だけを想定していて、コメントも空行もエラーになってしまうことです。</p>
|
||
<p>glibc の make では rpcgen というプログラムが使われることがあります。このプログラムの問題は、プリプロセッサの行番号情報の出力形式としてやはり GCC の</p>
|
||
<pre>
|
||
#123 "filename"
|
||
</pre>
|
||
<p>という形式だけを想定していて、</p>
|
||
<pre>
|
||
#line 123
|
||
</pre>
|
||
<p>も</p>
|
||
<pre>
|
||
#line 123 "filename"
|
||
</pre>
|
||
<p>もエラーになってしまうことです。
|
||
</p>
|
||
<p><b>mcpp</b> では GCC 版では GCC の形式をデフォルトにしました。しかし、rpcgen がこういう特殊な形式を前提にして、標準的な形式に対応していないというのは、お粗末な仕様です。</p>
|
||
|
||
<h4>3.9.4.9. -include, -isystem, -I- オプション</h4>
|
||
<p>glibc 2.1 の makefile では、-include オプションがしばしば使われています。時には -isystem オプションや -I- オプションも使われます。-include はソースの冒頭で #include すればすむもので、-isystem, -I- はシステムヘッダを更新する場合しか必要性の感じられないものです。<br>
|
||
<b>mcpp</b> では GCC 用の実装に限って、この３つのオプションも実装しましたが、あまり必要のないオプションは整理してもらいたいものです。*1</p>
|
||
<p>注:</p>
|
||
<p>*1 GCC / cpp にはこのほかに -iprefix, -iwithprefix, -iwithprefixbefore, -idirafter といった include directory とその順序を指定するオプションがいくつもある。また、long-file-name と MS-DOS 上の 8+3 形式のファイル名との対応表の使用を指定する -remap オプションもある。これらは CygWIN システムの specs ファイル等で使われることがあるが、include directory は環境変数で指定しておけばすむことであり、8+3 形式のファイル名への対応がいまさら CygWIN で必要だとも思えない。</p>
|
||
|
||
<h4>3.9.4.10. Undocumented な事前定義マクロ</h4>
|
||
<p>これは glibc の問題ではなく、GCC の問題です。</p>
|
||
<pre>
|
||
__VERSION__, __SIZE_TYPE__, __PTRDIFF_TYPE__, __WCHAR_TYPE__
|
||
</pre>
|
||
<p>以上の名前はドキュメントには見当たりませんが、GCC / cpp では事前定義マクロとなっています。<tt>__VERSION__</tt> の値は Vine Linux 2.1 (egcs-1.1.2) では "egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)" となっています。他の３つは Linux / i386 をはじめ多くのシステムではそれぞれ unsigned int, int, long int となっているようです。しかし、FreeBSD, CygWIN では少しずつ違っています（なぜ違う必要があるのかわからないが）。<br>
|
||
こういうことがどうしてドキュメントにないのでしょうか。</p>
|
||
|
||
<h4>3.9.4.11. Undocumented な環境変数</h4>
|
||
<p>もっとも奇怪なのは <samp>SUNPRO_DEPENDENCIES</samp> という undocumented な環境変数です。<samp>sysdeps/unix/sysv/linux/Makefile</samp> には</p>
|
||
<pre>
|
||
SUNPRO_DEPENDENCIES='$(@:.h=.d)-t $@' \
|
||
$(CC) -E -x c $(sysinclude) $< -D_LIBC -dM | \
|
||
... \
|
||
etc.
|
||
</pre>
|
||
<p>という script があります。これは <samp>SUNPRO_DEPENDENCIES</samp> という環境変数でファイル名を指定し、cpp がソース中のマクロ定義とソースファイルの依存関係行をその指定されたファイルに出力するというものなのです。</p>
|
||
<p>この動作を理解するには、GCC / cpp のソース (egcs-1.1.2/gcc/cccp.c) を読むしかありませんでした。<br>
|
||
このほか、<samp>DEPENDENCIES_OUTPUT</samp> という環境変数もあり、同様の意味を持っています。<samp>SUNPRO_DEPENDENCIES</samp> のほうは system headers の依存関係行も出力するのに対して、<samp>DEPENDENCIES_OUTPUT</samp> はそうではないという違いがあります。</p>
|
||
<p><b>mcpp</b> では GCC 対応版に限って、この２つの環境変数に対応させましたが、こういう「裏仕様」のようなものは早く廃止してほしいものです。</p>
|
||
|
||
<h4>3.9.4.12. その他の問題</h4>
|
||
<p>Linux (i386) / GCC ではこのほか、specs ファイルの指定によって、cpp の呼び出しに -Asystem(unix) -Acpu(i386) -Amachine(i386) というオプションが付加されます。しかし、これを利用するソースは少なくとも glibc 2.1.3 の Linux / x86 版にはないようです。<br>
|
||
Glibc からインストールされるシステムヘッダがつぎはぎだらけの非常に複雑なものになってきていることは、大きな問題です。ちょっとした設定の違いによって処理結果が違ってくる恐れがあります。</p>
|
||
<p>他方で、FreeBSD 2.2.2 / kernel ソースで見られた #else junk, #endif junk やマクロの二重定義は glibc 2.1.3 では見られませんでした。Glibc 2.1 のソースが FreeBSD 2 / kernel のソースより整理されている面もいくらかあります。</p>
|
||
<p>しかし全体としては、glibc 2.1 には GCC の特殊な仕様に依存しているソースが稀ならずあり、他の処理系への移植は困難になっています（数千本のソースファイルの中ではごく一部であるが）。プログラムの可読性やメンテナンス性のためにも、こうした GCC local な仕様への依存は好ましくありません。GCC V.3 ではこれらの裏技的仕様を廃止し、それに依存するソースを一掃することを期待したいと思います。</p>
|
||
|
||
<h3><a name="3.9.5" href="#toc.3.9.5">3.9.5. GCC 2 で <b>mcpp</b> を使うには</a></h3>
|
||
<p><b>mcpp</b> を glibc 2.1 のコンパイルに使うには、まず一部のソースの修正が必要です。*1<br>
|
||
一つは可変個引数のマクロの定義と呼び出しです。上記 3.9.4.3 にある 14 個のファイルについて、3.9.1.6 にあるような形で修正します。もちろん、元のファイルも残しておいたほうが良いでしょう。<br>
|
||
もう一つは、3.9.4.6 にある３つのファイルの、置換リストに "defined" が出てくるマクロの修正です。また、<samp>/usr/include/_G_config.h</samp> は <samp>sysdeps/unix/sysv/linux/_G_config.h</samp> が install されてできる同一のファイルですが、こちらも修正しておいたほうが良いでしょう。</p>
|
||
<p><b>mcpp</b> の起動には、Makefile や specs ファイルで付加されるオプションのほかに、行をまたぐ文字列リテラルやアセンブラ用のコメントを含む *.S ファイルのために -lang-asm (-x assembler-with-cpp) が必要です。このオプションは他のファイルのプリプロセスにも付けておいて、通常はかまいません。</p>
|
||
<p>GCC / cpp を使ったり <b>mcpp</b> を使ったり、デフォルトで付加するオプションを変更したりするためには、次のようにするのが良いでしょう。</p>
|
||
<p>Super-user になって、cpp の存在するディレクトリ（ここでは <samp>/usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66</samp> とする）に行きます。ここに GCC / cpp が cpp という名前で存在し、<b>mcpp</b> が mcpp という名前で install されているとします。まず、次のような内容の mcpp.sh という名前のファイルを作ります。*2</p>
|
||
<pre>
|
||
#!/bin/sh
|
||
/usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/mcpp -Q -lang-asm "$@"
|
||
</pre>
|
||
<p>-Q オプションはなくてもかまいませんが、大量の診断メッセージを記録するには付けたほうが良いでしょう。<br>
|
||
さらに、次のようなコマンドを打ち込みます。</p>
|
||
<pre>
|
||
chmod a+x mcpp.sh
|
||
mv cpp cpp_gnuc
|
||
ln -sf mcpp.sh cpp
|
||
</pre>
|
||
<p>こうしておくと、gcc が cpp を呼び出した時に、それにリンクされている mcpp.sh が実行され、<b>mcpp</b> に上記のオプションを（gcc の付加するオプションの前に）付加して呼び出します。</p>
|
||
<p>デフォルトのオプションを変更する時は、mcpp.sh を変更するなり、mcpp を直接呼び出すなりします。そして、GCC / cpp を使う時は</p>
|
||
<pre>
|
||
ln -sf cpp_gnuc cpp
|
||
</pre>
|
||
<p>とします。</p>
|
||
<p>注:</p>
|
||
<p>*1 <b>mcpp</b> V.2.7 からは GCC-specific-build にこれらの仕様が実装されたので、ソースを修正しなくてもプリプロセスはできるようになった。</p>
|
||
<p>*2 <b>mcpp</b> を configure してインストールした場合は自動的に適切な設定がされる。
|
||
あとは -Q -lang-asm オプションを追加するだけですむ。</p>
|
||
|
||
<h4><a name="3.9.5.1" href="#toc.3.9.5.1">3.9.5.1. <b>mcpp</b> のウォーニングを整理するには</a></h4>
|
||
<p><b>mcpp</b> を使う場合のもう一つの問題は、大量のウォーニングが出力されることです。-Q オプションでリダイレクトしても、glibc のような大規模なソースを処理すると mcpp.err が総計数百 MB 以上になるので、すべてに目を通すわけにはいきません。<br>
|
||
しかし、この内容を見ると、同じウォーニングが繰り返し出ていることがわかります。同じ *.h ファイルが多くのソースから #include されるために、同じウォーニングが繰り返し繰り返し出るのです。これを整理して見るには、次のようにします。<br>
|
||
まず、エラーをチェックします。</p>
|
||
<pre>
|
||
grep 'fatal:' `find . -name mcpp.err`
|
||
grep 'error:' `find . -name mcpp.err`
|
||
</pre>
|
||
<p>次に、ウォーニングを整理します。
|
||
</p>
|
||
<pre>
|
||
grep 'warning:' `find . -name mcpp.err` | sort -k3 -u > mcpp-warnings-sorted
|
||
</pre>
|
||
<p>ウォーニングの出所をすべて見るためには、次のようにします。
|
||
</p>
|
||
<pre>
|
||
grep 'warning:' `find . -name mcpp.err` | sort -k3 | uniq > mcpp-warnings-all
|
||
</pre>
|
||
<p>特定の種類のウォーニングを見るには、たとえば次のようにします。
|
||
</p>
|
||
<pre>
|
||
grep 'warning: Replacement' `find . -name mcpp.err` | sort -k3 | uniq | less
|
||
</pre>
|
||
<p>こうして見当をつけたうえで、該当する mcpp.err を less で見て内容を確認し、必要ならソースを見ます。<br>
|
||
さらに必要なら、ソースの問題の個所を #pragma MCPP debug expand, #pragma MCPP end_debug 等で挟んで再度プリプロセスして、その出力を見ます。この時には、プリプロセスの出力と診断メッセージとが同じファイルに出るように、次のようにします（make する場合は、上記の shell-script を一時書き換える）。</p>
|
||
<pre>
|
||
mcpp <-opts> in-file.c > in-file.i 2>&1
|
||
</pre>
|
||
|
||
<h3><a name="3.9.6" href="#toc.3.9.6">3.9.6. GCC 3.2 ソースのプリプロセス</a></h3>
|
||
<p>Linux および FreeBSD で、GCC 2.95.* で GCC 3.2R (2002/08) のソースをコンパイルしてみました。そして、生成された gcc を使って <b>mcpp</b> をコンパイルし、次にプリプロセスにそれを使って GCC 3.2 で GCC 3.2 のソースをリコンパイルしてみました。</p>
|
||
<p>GCC の make はいくつかの段階を経て bootstrap されてゆくようになっています。すなわち、最初の段階で生成された gcc, cc1, etc. を使って自分自身をリコンパイルし、そうやって再生成されたものを使ってまた自分自身をリコンパイルし、といった経過をたどります。gcc は bootstrap の途中では xgcc という名前で存在しています。</p>
|
||
<p>また、GCC 2 では cc1, cc1plus からは独立していた cpp が、GCC 3 では cc1, cc1plus に吸収されてしまいました。しかし、独立したプリプロセッサである cpp0 も存在しており、gcc や g++ に -no-integrated-cpp というオプションを付けるとこれにプリプロセスをさせることができるようになっています。したがって、<b>mcpp</b> にプリプロセスをさせるためには、gcc (xgcc), g++ の呼び出しを shell-script に置き換えて、<b>mcpp</b> => cc1 または <b>mcpp</b> => cc1plus という順序で実行されるようにしなければなりません。*1</p>
|
||
<p>GCC のシステムでは、システムヘッダやそのサーチ順の設定が非常に複雑になってきています。また、GCC 3 では GCC が内部的に使う C++ の shared library の仕様が GCC 2 とは変わったようです。これらのためか、コンパイルするだけでもうまくゆかないことがあります。また、コンパイルとテストには多くの他のソフトウェアも必要で、それらのバージョンが古いと、うまくゆかないことがあります。私のところではハードウェアの問題でうまくコンパイルできないこともありました。</p>
|
||
<p>FreeBSD 4.4R では GCC 3.2 はコンパイルできませんでした。FreeBSD を 4.7R に upgrade し、packages を 4.7 用のものに入れ替えて、ようやくコンパイルすることができました。*2<br>
|
||
私のところでは２台のパソコンに同じ VineLinux 2.5 が入っていますが、その片方 (K6/200MHz) では GCC 2.95.3 を使ってのコンパイルはできたものの、生成された GCC 3.2 / cc1 が segmentation fault を繰り返し起こしてしまい、自分自身のリコンパイルができませんでした。その後、K6 を AthlonXP に取り替えてリコンパイルしたところ、今度は segmentation fault は発生しませんでした。問題はハードウェアだったのかもしれません。<br>
|
||
また、FreeBSD では K6 のパソコンで GCC 2.95.4 を使って GCC 3.2 をコンパイルした時は、make -k check ではほとんどすべて通ったのですが、さらに生成された GCC 3.2 で GCC 3.2 自身をリコンパイルしたところ、今度は、g++, libstdc++-v3 が make -k check で testsuite の２割近くが通らないという現象も起こりました。しかし、AthlonXP に取り替えてからはうまくゆくようになりました。これもハードウェアの問題だったのかもしれません。</p>
|
||
<p>また、VineLinux で GCC 3.2 自身と <b>mcpp</b> を使ってリコンパイルした場合は、生成された gcc は make -k check を通りましたが、g++, libstdc++-v3 は testsuite の２割近くが通りませんでした。*3, *4, *5<br>
|
||
どちらにしても、生成された gcc, g++, cc1, cc1plus 等の問題ではなく、ヘッダファイルかライブラリか何かの設定の微妙な問題のようです。<br>
|
||
<b>mcpp</b> は GCC とは完全に互換ではありませんが、かなり高い互換性をもっているので、取り替えて使ってほぼ問題はないと思われます。</p>
|
||
<p>GCC 3.2 のコンパイルに使ったシステムは次のものです。</p>
|
||
<blockquote>
|
||
<table>
|
||
<tr><th>OS </th><td>make </td><td>library </td><td>CPU</td></tr>
|
||
<tr><th>VineLinux 2.5</th><td>GNU make</td><td>glibc 2.2.4</td><td>Celeron/1060MHz</td></tr>
|
||
<tr><th>VineLinux 2.5</th><td>GNU make</td><td>glibc 2.2.4</td><td>K6/200MHz</td></tr>
|
||
<tr><th>VineLinux 2.5</th><td>GNU make</td><td>glibc 2.2.4</td><td>AthlonXP/2.0GHz</td></tr>
|
||
<tr><th>FreeBSD 4.7R </th><td>UCB make</td><td>libc.so.4 </td><td>K6/200MHz</td></tr>
|
||
<tr><th>FreeBSD 4.7R </th><td>UCB make</td><td>libc.so.4 </td><td>AthlonXP/2.0GHz</td></tr>
|
||
</table>
|
||
</blockquote>
|
||
<p>コンパイルしたのは C と C++ だけです。</p>
|
||
<p>注:</p>
|
||
<p>*1 これを bootstrap の各段階ごとにやらなければならないのである。
|
||
Makefile は手を入れるにはあまりに大きく複雑なので、画面に張り付いていて、stage が変わったところで ^C で中断して、script に置き換えるという不細工な方法をとった。</p>
|
||
<p>*2 しかも、多くの packages の間の依存関係があるので、バージョンがまちまちだと混乱が生じる。私のところではこのために、一時は kterm が起動しないという状態に陥ったこともある。</p>
|
||
<p>*3 make -k check する時は <b>mcpp</b> は使ってはいけない。診断メッセージが GCC とは異なるからである。</p>
|
||
<p>*4 make -k check する時は環境変数 LANG, LC_ALL を C として、英語環境にしないといけない。</p>
|
||
<p>*5 Testsuite が通らない直接の原因はすべて、<samp>i686-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.5.0.0</samp> というライブラリで pthread_getspecific, pthread_setspecific 等 pthread_* という関数がリンクできないというものである。正しく生成されたこのライブラリを入れてやれば、make -k check は通る。FreeBSD ではこの問題は起こらない。何かの設定の微妙な問題のようである。</p>
|
||
|
||
<h4>3.9.6.1. 行をまたぐ文字列リテラル</h4>
|
||
<p>このあまりにも古い書き方は GCC 3.2 のソースにはありません。この仕様は GCC 3.2 でようやく obsolete とされました。ソース中にこれがあると、期待通りに処理はされますが、ウォーニングが出ます。</p>
|
||
|
||
<h4>3.9.6.2. #include_next, #warning</h4>
|
||
<p>Make の途中で生成される <samp>build/gcc/include</samp> の limits.h, syslimits.h には #include_next があり、GCC 3.2 を install すると、<samp>lib/gcc-lib/i686-pc-linux-gnu/3.2/include</samp> の limits.h, syslimits.h にコピーされます。</p>
|
||
<p>#warning は見当たりませんでした。</p>
|
||
|
||
<h4><a name="3.9.6.3">3.9.6.3. 可変引数マクロ</a></h4>
|
||
<p>可変引数マクロはいくつかありますが、大半は testsuite のもので、テスト用に書かれたサンプルにすぎません。そして、GCC 2 以来の記法はまだサポートされてはいるものの、<samp>__VA_ARGS__</samp> を使った C99 のものが多くなっています。</p>
|
||
<p>また、GCC 3 では GCC 2 の仕様と C99 の仕様との折衷的な書き方が追加されています。次の形です。*1</p>
|
||
<pre>
|
||
#define eprintf( fmt, ...) fprintf( stderr, fmt, ##__VA_ARGS__)
|
||
</pre>
|
||
<p>これは GCC 2 仕様の次の書き方に対応します。</p>
|
||
<pre>
|
||
#define eprintf( fmt, args...) fprintf( stderr, fmt, ##args)
|
||
</pre>
|
||
<p>これは、<samp>...</samp> に対応する引数がなかった時は、その直前のコンマを削除するという仕様です。たとえば、次のように展開されます。</p>
|
||
<pre>
|
||
eprintf( "success!\n") ==> fprintf( stderr, "success!\n")
|
||
</pre>
|
||
<p>この例を見ると便利な仕様のようですが、マクロ定義の置換リスト中のコンマはパラメータを区切るものとは限らないこと、トークン連結演算子である ## に別の働きをさせていること、規則に例外を作って複雑にするものであること、等の問題があります。*2, *3, *4</p>
|
||
<p>注:</p>
|
||
<p>*1 このマニュアルでは、GCC 2 以来の可変引数マクロを GCC2 仕様、GCC 3 で追加されたものを GCC3 仕様と呼ぶことにする。</p>
|
||
<p>*2 GCC 2.* では GCC2 仕様の可変引数マクロの定義の <samp>args...</samp> 等では <samp>args</samp> と <samp>...</samp> とはくっついていなければならなかったが、GCC 3 では間に space が入っていても良くなった。</p>
|
||
<p>*3 ただし、-ansi オプションが指定された場合（-std=c*, -std=iso* オプションでも同様）、可変引数が存在しなくてもコンマは削除されない。
|
||
しかし、'##' は黙って消え去る。</p>
|
||
<p>*4 <b>mcpp</b> では V.2.6.3 から GCC-specific-build の <i>STD</i> モードに限って、GCC3 仕様の可変引数マクロも実装された。
|
||
さらに V.2.7 からは GCC2 仕様のものにも対応した。</p>
|
||
|
||
<h4>3.9.6.4. マクロ呼び出しのカラ引数</h4>
|
||
<p>マクロ呼び出しのカラ引数は、#include されるシステムヘッダのもの（<samp>/usr/include/bits/mathcalls.h, /usr/include/bits/sigset.h</samp>）を別とすると、GCC 3.2 のソース自体では、<samp>gcc/libgcc2.h</samp> にだけ見られます。*1</p>
|
||
<p>注:</p>
|
||
<p>*1 この２つのヘッダファイルは glibc を install することでシステムヘッダに入ってゆくものである。FreeBSD では glibc を使っていないので、これらのシステムヘッダは存在しない。</p>
|
||
|
||
<h4>3.9.6.5. Function-like マクロの名前に置換される object-like マクロ</h4>
|
||
<p><samp>gcc/fixinc/gnu-regex.c, libiberty/regex.c</samp> には、function-like マクロの名前に置換される object-like マクロの定義が見られます。また、#include される <samp>/usr/lib/bison.simple</samp> も同様です。これらはすべて alloca に関するものです。たとえば、<samp>libiberty/regex.c</samp> にはこういうマクロ定義があります。</p>
|
||
<pre>
|
||
#define REGEX_ALLOCATE alloca
|
||
#define alloca( size) __builtin_alloca( size)
|
||
</pre>
|
||
<p>これは、こう書けば問題ないのですが、なぜこんなところを省略するのでしょうか。</p>
|
||
<pre>
|
||
#define REGEX_ALLOCATE( size) alloca( size)
|
||
</pre>
|
||
<p>この regex.c では alloca は場合によっては次のように定義されるようになっており、スタイルが一貫していません。</p>
|
||
<pre>
|
||
#define alloca __builtin_alloc
|
||
</pre>
|
||
<p>また、regex.c には #include "regex.c" という行があり、自分自身をインクルードするようになっています。複雑怪奇なソースです。</p>
|
||
|
||
<h4>3.9.6.6. 'defined' に展開されるマクロ</h4>
|
||
<p>これは GCC 3.2 のソースには見当たりません。</p>
|
||
<p>ドキュメントによると、この種のマクロの処理は GCC 2 / cpp と同じであるものの、「portability がない」というウォーニングを出すことになっています。ただ、テストしてみると、3.9.4.6 の例ではウォーニングが出ません。</p>
|
||
|
||
<h4>3.9.6.7. .S ファイルの「プリプロセス」</h4>
|
||
<p>GCC 3 / cpp のドキュメントには、次のように書かれています。</p>
|
||
<blockquote>Wherever possible, you should use a preprocessor geared to the
|
||
language you are writing in. Modern versions of the GNU assembler have
|
||
macro facilities.</blockquote>
|
||
<p>しかし、GCC 3.2 自身のソースには、*.S ファイルが <samp>gcc/config</samp> ディレクトリに数本あります。</p>
|
||
|
||
<h4>3.9.6.8. rpcgen と -dM オプションの仕様の問題</h4>
|
||
<p>GCC 3.2 の make では rpcgen も -dM オプションも使われませんでした。しかし、rpcgen や -dM オプションの仕様は特に変わってはいないようです。</p>
|
||
|
||
<h4>3.9.6.9. -include, -isystem, -I- オプション</h4>
|
||
<p>これらのオプションはしばしば使われており、-isystem オプションで system include directory が同時に数個指定される場合さえあります。こういう、システムヘッダそのものを更新するソフトウェアのコンパイルでは、やむをえないことなのでしょうか。環境変数で一括して指定したほうが、わかりやすいと思うのですが。</p>
|
||
<p>一方で、GCC 3 / cpp のドキュメントでは、-iwithprefix, -iwithprefixbefore オプションについては、「使わないほうが良い (discouraged)」と書かれています。GCC には include directory を指定するオプションがやたらにありますが、整理する方向に入ってきたのでしょうか。*1</p>
|
||
<p>注:</p>
|
||
<p>*1 しかし、GCC 3.2 の Makefile は -iprefix オプションを付けている。
|
||
ところが -iwithprefix, -iwithprefixbefore は使われないのである。-iprefix オプションは、その後にこの２つのオプションのどちらかがあって初めて意味を持つのであるが。</p>
|
||
|
||
<h4>3.9.6.10. Undocumented な事前定義マクロ</h4>
|
||
<p>GCC 2 では <tt>__VERSION__</tt>, <tt>__SIZE_TYPE__</tt>, <tt>__PTRDIFF_TYPE__</tt>, <tt>__WCHAR_TYPE__</tt> 等の事前定義マクロについては、ドキュメントに記載がなく、-dM オプションでも知ることができませんでしたが、GCC 3 ではドキュメントに意味が記載され、具体的な値も -dM で知ることができるようになりました。</p>
|
||
|
||
<h4>3.9.6.11. Undocumented な環境変数</h4>
|
||
<p>GCC 2 ではドキュメントに記載のなかった <tt>SUNPRO_DEPENDENCIES</tt> という環境変数については、GCC 3 ではドキュメントに記載されるようになりました（しかし、なぜこんなものが必要なのかはわからない）。</p>
|
||
|
||
<h4>3.9.6.12. その他の問題</h4>
|
||
<p>GCC 3 では次のような #pragma が実装されています。</p>
|
||
<pre>
|
||
#pragma GCC poison
|
||
#pragma GCC dependency
|
||
#pragma GCC system_header
|
||
</pre>
|
||
<p>GCC 3.2 のソースでも、このうち poison と system_header が使われています。しかし、<b>mcpp</b> ではこれらはサポートしていません。仕様の説明は省きますが、必要性があまり感じられないからです。*1</p>
|
||
<p>GCC 3 では #assert 等の assertion directives は「推奨しない (deprecated)」とされました（しかし、gcc はデフォルトで -A オプションを発行するが）。</p>
|
||
<p>また、GCC 2 では -traditional オプションは同一の cpp で実装されており、そのため非常に古い仕様と C90 の仕様が混在する奇怪な仕様となっていましたが、GCC 3.2 ではプリプロセッサが通常の cpp0 と tradcpp0 とに分けられました。-traditional オプションは gcc に対してだけ有効で、cpp0 にはありません。gcc -traditional はプリプロセスに tradcpp0 を呼び出します。tradcpp0 は C90 以前の真に traditional なプリプロセッサに近いものとなっています。そして、tradcpp0 のほうは今後、深刻なバグの修正以外はメンテナンスしないとされています。</p>
|
||
<p>GCC 2 / cpp の奇妙な仕様はだいぶ修正されてきたように見えます。</p>
|
||
<p>注:</p>
|
||
<p>*1 <b>mcpp</b> V.2.7 からは GCC-specific-build で #pragma GCC system_header をサポートした。</p>
|
||
|
||
<h3><a name="3.9.7" href="#toc.3.9.7">3.9.7. GCC 3, 4 で <b>mcpp</b> を使うには</a></h3>
|
||
<p>以上に見てきたように、GCC 3.2 のソースは少なくともプリプロセス上は、glibc 2.1.3 などに比べるとかなりきれいなものになっています。Traditional な書き方はほぼ一掃され、意味のないオプションは使われなくなってきています。<br>
|
||
また、GCC 3.2 / cpp0 そのものも、traditional な仕様を obsolete なものとして扱い、token-based な原則を明確にするなど、GCC 2 / cpp に比べると格段に優れたものとなっています。ドキュメントも undocumented な部分が大幅に減りました。まだ不徹底な面も多々ありますが、方向としては良い方向に向かっていると思われます。</p>
|
||
<p>ただ、GNU のシステムではシステムヘッダが複雑化する一方で、何がどうなっているのか容易に把握できないようになっています。これが GNU のシステムのトラブルの最大の要因となってくるのではないでしょうか。</p>
|
||
<p>もう一つ残念なのは、プリプロセスがコンパイラ本体に吸収されてしまったことです。そのため、<b>mcpp</b> を使うには gcc や g++ を -no-integrated-cpp というオプションを付けて呼び出す必要があります。複雑な makefile や多くの makefile を持つ大きなソースファイル群をコンパイルする場合や、何かのプログラムから gcc が自動的に呼び出される場合は、gcc, g++ の呼び出しを shell-script に置き換えて、このオプションが自動的に付加されるようにしなければなりません。</p>
|
||
<p>具体的には、gcc, g++ の置かれているディレクトリ（私の Linux の例では <samp>/usr/local/gcc-3.2/bin</samp>）に次のような script をそれぞれ gcc.sh, g++.sh という名前で置きます。</p>
|
||
<pre>
|
||
#!/bin/sh
|
||
/usr/local/gcc-3.2/bin/gcc_proper -no-integrated-cpp "$@"
|
||
</pre>
|
||
<pre>
|
||
#!/bin/sh
|
||
/usr/local/gcc-3.2/bin/g++_proper -no-integrated-cpp "$@"
|
||
</pre>
|
||
<p>そして、このディレクトリで次のようにします。</p>
|
||
<pre>
|
||
chmod a+x gcc.sh g++.sh
|
||
mv gcc gcc_proper
|
||
mv g++ g++_proper
|
||
ln -sf gcc.sh gcc
|
||
ln -sf g++.sh g++
|
||
</pre>
|
||
<p>また、cpp の置かれているディレクトリ（私の Linux の例では <samp>/usr/local/gcc-3.2/lib/gcc-lib/i686-pc-linux-gnu/3.2</samp>）で、GCC 2 の場合と同様に、cpp0 の呼び出しで <b>mcpp</b> が実行されるようにしておきます（<a href="#3.9.5"> 3.9.5</a> 参照）。*1<br>
|
||
こうしておくと、gcc や g++ からまず <b>mcpp</b> が呼び出され、その後に cc1, cc1plus が -fpreprocessed というプリプロセス済みであることを示すオプションを付けて呼び出されるようになります。</p>
|
||
<p>なお、システムの標準と異なるバージョンの GCC をインストールした場合は付加的な include directory の設定が必要なことがありますが、<b>mcpp</b> ではこれらも <b>mcpp</b> のコンパイル時に組み込むので、通常は環境変数で設定する必要はありません。</p>
|
||
<p>できれば cc1, cc1plus のプリプロセス部分である cpplib のソースを <b>mcpp</b> のものに置き換えたいところですが、cpplib の cc1, cc1plus との内部的な interface および cpplib を使うユーザプログラムとの外部的な interface を定義しているソースファイルが合わせて 46KB もあり、とても置き換えは不可能です。どうしてこういう複雑な interface にする必要があるのでしょうか。残念なことです。</p>
|
||
<p>注:</p>
|
||
<p>*1 configure して <b>mcpp</b> をインストールした場合は、これらが自動的に設定される。</p>
|
||
|
||
<h4>3.9.7.1. GCC 3.3, 3.4-4.1 で <b>mcpp</b> を使うには</h4>
|
||
<p>良い方向に向かっていた GCC V.3 でしたが、V.3.3 からは妙な方向に転換してしまいました。V.3.3 は V.3.2 と比べると、次のような点で大きく変わっています。</p>
|
||
<ol>
|
||
<li>単体の cpp0 はなくなった。gcc -no-integrated-cpp はまだ使えるが、そこから呼び出されるのは cc1 (cc1plus) である。すなわち、プリプロセスでもコンパイルでも cc1 が呼び出される。そして、プリプロセスフェーズの cc1 にプリプロセス用でないオプションがしばしば渡される（何という汚い実装！）。<br>
|
||
<li>60 個から 70 個の大量のマクロが事前定義されている。これによってシステムヘッダと GCC との関係がさらに複雑になった。<br>
|
||
<li>tradcpp もなくなり、GCC V.3.2 では obsolete とか deprecated とされた古い仕様の一部が復活した。<br>
|
||
</ol>
|
||
<p>全体として、１つの巨大なコンパイラにすべてを吸収する方向となっており、Ｃ処理系の構成のしかたとしても、オープンソースの処理系の開発の方向としても、大いに疑問のあるところです。</p>
|
||
<p><b>mcpp</b> の移植では、gcc からどんなオプションが渡されてくるかわからないというのが困るところです。間違ったオプションもすべてチェックせずに無視するのでは危険があります。とりあえず、しばしば間違って渡されてくるオプションは無視するようにしましたが、それ以外のオプションが渡されるとエラーになるはずです。<br>
|
||
これだけの変更でも、<b>mcpp</b> の従来のオプションの中には使えなくなったものがあります。V.2.5 からは -E オプションは廃止し、-m オプションは -e に、-c は -@compat に変更しました。<br>
|
||
また、GCC V.3.2 では cpp0 の呼び出しを <b>mcpp</b> に置き換えればすんだところが、今度は cc1 (cc1plus) の呼び出しを <b>mcpp</b> と cc1 (cc1plus) とに振り分けることが必要になります。このための shell-script は src/set_mcpp.sh の中に用意しました。大量の事前定義マクロは１つ１つ対応しているわけにはいかないので、GCC の -dM オプションの出力を一括して利用するようにしました。*1, *2, *3</p>
|
||
<p>GCC V.3.4 ではさらに、multi-byte character はすべて UTF-8 に変換してから処理するように変わりました。ドキュメントによると、具体的には次のようになっています。*4</p>
|
||
<ol>
|
||
<li>プリプロセスの最初のフェーズで、multi-byte character を UTF-8 に変換する。<br>
|
||
<li>この変換には libiconv の関数を使う。したがって、iconv が対応している encoding はすべて使える。<br>
|
||
<li>ソースファイルの encoding を指定するには -finput-charset=<encoding> オプションを使う。（実際には、これを指定しなければ UTF-8 には変換されない）。<br>
|
||
<li>コンパイル後の encoding はデフォルトでは UTF-8 であるが、-fexec-charset=<encoding> オプションで他の encoding を指定することができる。*5<br>
|
||
</ol>
|
||
<p>「国際化」と言えば Unicode に対応させることと考える風潮が、ことに実際に multi-byte character を使わない西欧の人々の間にありますが、この風潮が GCC にも及んでしまったようです。</p>
|
||
<p>しかも、仕様がまだ十分に実装されていません。実際に使ってみると、次のようになります。</p>
|
||
<ol>
|
||
<li>EUC-JP, GB2312, KSC-5601, Big5 は -finput-charset オプションを指定すると UTF-8 に正しく変換され、指定しなければそのまま通る。*6<br>
|
||
<li>-fexec-charset オプションは V.3.4, 4.0 では効かなかったが、V.4.1-4.3 では効く。<br>
|
||
<li>ISO2022-JP は V.3.4, 4.0 では処理できなかったが、V.4.1-4.3 ではできる。<br>
|
||
<li>どのバージョンでも shift-JIS は -finput-charset を指定するとかえって混乱してしまう。<br>
|
||
</ol>
|
||
<p><b>mcpp</b> は -e <encoding> オプションで encoding を指定しますが、GCC-specific-build では、BIG5, shift-JIS, ISO2022-JP では <backslash> 等と一致する値のバイトの直前に <backslash> を挿入してコンパイラの欠陥を補います。しかし、UTF-8 には変換せず、元の encoding のまま出力します。-finput-charset オプションも -e オプションと同じものとして扱います。これは次のような理由です。*7</p>
|
||
<ol>
|
||
<li>SJIS は -f*-charset を指定すると、どのバージョンの GCC でもダメである。しかし、どのバージョンの GCC でも、SJIS, JIS, BIG5 は変換せずに <backslash> を補ってやるとそのまま通り、期待通りの結果になる。
|
||
EUC-JP, GB2312, KSC-5601 も変換しなければそのまま通る。
|
||
すなわち、single byte character sequence であるかのように扱われる。<br>
|
||
<li>GCC 4.0 までのバージョンではどの encoding も UTF-8 から元の encoding に戻せない。<br>
|
||
<li>GCC の近い将来の仕様変更を期待したい。<br>
|
||
</ol>
|
||
<p>注:<p>
|
||
<p>*1 しかし、-dM オプションの出力は他のオプションによって少し違ってくるのである。
|
||
しかも、これらの事前定義マクロの大半は undocumented なものである。
|
||
このため、全容はなかなか把握できない。</p>
|
||
<p>*2 MinGW では symbolic link が使えない。ln -s というコマンドはあるが、これは単にコピーするだけのものである。また、MinGW の GCC はたとえ cc1 という名前のファイルであってもそれが shell-script であると、起動を拒否する。そのため、<b>mcpp</b> の GCC-specific-build では、MinGW に限って cc1.exe という名前の実行プログラムを生成する（これは cc1plus.exe にもコピーされる）。そして、その中から mcpp.exe または GCC の cc1.exe ないし cc1plus.exe を起動するようにしている。</p>
|
||
<p>*3 CygWIN / GCC では -mno-cygwin というオプションがあり、これを指定すると system include directory が変わり、GCC の事前定義マクロも変わる。このため、<b>mcpp</b> の CygWIN GCC-specific-build では V.2.6.1 からは２セットの事前定義マクロを用意するようにした。</p>
|
||
<p>*4 私のところの FreeBSD 6.3 ではなぜか GCC のこの変換はまったく動作しない。libiconv はリンクされているのであるが。
|
||
FreeBSD 5.3, 6.2 でもそうであった。</p>
|
||
<p>*5 この変換はプリプロセスフェーズではなく、コンパイルフェーズで行われるようである。
|
||
-E オプションの出力は UTF-8 のままである。</p>
|
||
<p>*6 しかし、GCC V.4.1-4.3 では、-save-temps または -no-integrated-cpp オプションを -f*-charset オプションと同時に指定すると、エラーになるというバグがある。
|
||
<p>*7 <b>mcpp</b> の出力を cc1 に渡す時には -finput-charset はもちろん -fexec-charset オプションも付けてはいけない。</p>
|
||
|
||
<h3><a name="3.9.8" href="#toc.3.9.8">3.9.8. Linux / glibc 2.4 ソースのプリプロセス</a></h3>
|
||
|
||
<p>glibc 2.4 (2006/03) のソースをコンパイルして、プリプロセスをチェックしてみました。
|
||
処理系は GCC 4.1.1 で、プリプロセッサを <b>mcpp</b> 2.6.3 に置き換えたものです。
|
||
マシンは x86 系なので、他の CPU 用のコードはチェックしていません。</p>
|
||
<p>以前に私がチェックした glibc 2.1.3 (2000/02) から６年経ったバージョンなので、大きく変わったところももちろんありますが、意外に変わっていないところも多く見られます。
|
||
全体としては、以前のバージョンについて私が取り上げた問題点は整理されずに、むしろ増える傾向にあります。</p>
|
||
|
||
<h4>3.9.8.1. 行をまたぐ文字列リテラル</h4>
|
||
|
||
<p>行をまたぐ文字列リテラルは見られなくなりました。</p>
|
||
|
||
<h4>3.9.8.2. #include_next, #warning</h4>
|
||
|
||
<p>次のファイルには #include_next があります。
|
||
５年半前のバージョンと比べると増えています。</p>
|
||
|
||
<p><samp>
|
||
catgets/config.h,
|
||
elf/tls-macros.h,
|
||
include/bits/dlfcn.h,
|
||
include/bits/ipc.h,
|
||
include/fpu_control.h,
|
||
include/limits.h,
|
||
include/net/if.h,
|
||
include/pthread.h,
|
||
include/sys/sysctl.h,
|
||
include/sys/sysinfo.h,
|
||
include/tls.h,
|
||
locale/programs/config.h,
|
||
nptl/sysdeps/pthread/aio_misc.h,
|
||
nptl/sysdeps/unix/sysv/linux/aio_misc.h,
|
||
nptl/sysdeps/unix/sysv/linux/i386/clone.S,
|
||
nptl/sysdeps/unix/sysv/linux/i386/vfork.S,
|
||
nptl/sysdeps/unix/sysv/linux/sleep.c,
|
||
sysdeps/unix/sysv/linux/ldsodefs.h,
|
||
sysdeps/unix/sysv/linux/siglist.h
|
||
</samp></p>
|
||
|
||
<p>次のファイルは make check で使われるテスト用のものですが、ここにも #include_next があります。</p>
|
||
|
||
<p><samp>sysdeps/i386/i686/tst-stack-align.h</samp></p>
|
||
|
||
<p>#warning は <samp>sysvipc/sys/ipc.h</samp> にありますが、正常にコンパイルされるときはスキップされるブロックにあるので、ひっかかることはありません。</p>
|
||
|
||
<h4>3.9.8.3. 可変引数マクロ</h4>
|
||
|
||
<p>次のファイルには可変引数マクロの定義がありますが、これらはすべて GCC2 以来の古い仕様のマクロです。
|
||
C99 の仕様のものはおろか、GCC3 仕様のものさえも見当たりません。</p>
|
||
|
||
<p><samp>elf/dl-lookup.c,
|
||
elf/dl-version.c,
|
||
include/libc-symbols.h,
|
||
include/stdio.h,
|
||
locale/loadlocale.c,
|
||
locale/programs/ld-time.c,
|
||
locale/programs/linereader.h,
|
||
locale/programs/locale.c,
|
||
locale/programs/locfile.h,
|
||
nptl/sysdeps/pthread/setxid.h,
|
||
nss/nss_files/files-XXX.c,
|
||
nss/nss_files/files-hosts.c,
|
||
sysdeps/generic/ldsodefs.h,
|
||
sysdeps/i386/fpu/bits/mathinline.h,
|
||
sysdeps/unix/sysdep.h,
|
||
sysdeps/unix/sysv/linux/i386/sysdep.h</samp></p>
|
||
|
||
<p>次はテスト用のルーチンですが、ここにも GCC2 仕様の可変引数マクロの定義があります。</p>
|
||
|
||
<p><samp>localedata/tst-ctype.c,
|
||
posix/bug-glob2.c,
|
||
posix/tst-gnuglob.c,
|
||
stdio-common/bug13.c</samp></p>
|
||
|
||
<p>しかも実際にこれらのマクロを呼び出すときには、可変引数が１つもない（カラ引数さえもない）変則的な呼び出しがきわめて多くなっています。
|
||
この種の変則的なマクロ呼び出しは 142 本ものソースファイルに見られます。
|
||
そのうち、置換リストで可変引数の直前に ", ##" という sequence があってこの ',' が削除されるケースは、120 本のソースに見られます。<p>
|
||
<p>可変引数マクロは C99 の仕様を使ったほうが portable で良いのですが、GCC2 あるいは GCC3 仕様の可変引数マクロを C99 仕様のものに書き直すのは、必ずしも簡単ではありません。
|
||
GCC2 あるいは GCC3 仕様では実際のマクロ呼び出しで可変引数がない場合、その直前のコンマが削除されるので、マクロの呼び出し方によっては C99 仕様とは１対１に対応しないからです。
|
||
マクロ定義を C99 仕様に書き換えた場合、コンマを削除しないですむようにするためには、マクロ呼び出しのほうも書き直す必要があります。</p>
|
||
<p>glibc 2.1.3 ではまだこれらのマクロの数がさほど多くはなかったので、ユーザが目で確かめながらエディタで書き換えることができましたが、glibc 2.4 では数が増え、しかもそれらのマクロの呼び出し個所が大幅に増えたため、ユーザが書き換えることは不可能になりました。</p>
|
||
<p>このため、<b>mcpp</b> では V.2.6.3 から GCC-specific-build に限って、GCC3 仕様の可変引数マクロも実装しました。
|
||
さらに V.2.7 からは GCC2 仕様のものにも対応しました。
|
||
しかし、GCC2 仕様のものは token-based な原則から掛け離れているので、それを使うマクロを新しく書くべきではありません。
|
||
GCC2 仕様は GCC3 仕様と１対１に対応しているので、マクロ定義を GCC3 仕様に書き直すことは容易にでき、マクロ呼び出しを書き直さなくてもすみます。
|
||
すでに GCC2 仕様で書かれているマクロはこう書き換えたほうが、いくらかわかりやすくなります。*1</p>
|
||
<p>GCC2 仕様の可変引数マクロを GCC3 仕様に書き直すには、例えば次のようなものを</p>
|
||
|
||
<pre>
|
||
#define libc_hidden_proto(name, attrs...) hidden_proto (name, ##attrs)
|
||
</pre>
|
||
|
||
<p>次のようにします。</p>
|
||
|
||
<pre>
|
||
#define libc_hidden_proto(name, ...) hidden_proto (name, ## __VA_ARGS__)
|
||
</pre>
|
||
|
||
<p>すなわち、パラメータの <samp>attrs...</samp> を <samp>...</samp> にし、置換リスト中の <samp>attrs</samp> を <samp>__VA_ARGS__</samp> にします。</p>
|
||
|
||
<p>注:</p>
|
||
<p>*1 GCC2 仕様および GCC3 仕様の可変引数マクロについては、<a href="#3.9.1.6">3.9.1.6</a>, <a href="#3.9.6.3">3.9.6.3</a> を参照のこと。</p>
|
||
|
||
<h4>3.9.8.4. マクロ呼び出しのカラ引数</h4>
|
||
|
||
<p>カラ引数のあるマクロ呼び出しはきわめて多く、488 本ものソースファイルに見られます。
|
||
以前のバージョンと比べても大幅に増えました。
|
||
C99 でカラ引数が公認されたことが影響しているのでしょうか。</p>
|
||
|
||
<p>ことに <samp>math/bits/mathcalls.h</samp> には 79 個ものカラ引数マクロ呼び出しがあります。
|
||
以前とほぼ同様です。</p>
|
||
|
||
<h4>3.9.8.5. Function-like マクロの名前に置換される object-like マクロ</h4>
|
||
|
||
<p>次のファイルには function-like マクロの名前に置換される object-like マクロの定義が見られます。</p>
|
||
|
||
<p><samp>argp/argp-fmtstream.h,
|
||
hesiod/nss_hesiod/hesiod-proto.c,
|
||
intl/plural.c,
|
||
libio/iopopen.c,
|
||
nis/nss_nis/nis-hosts.c,
|
||
nss/nss_files/files-hosts.c,
|
||
nss/nss_files/files-network.c,
|
||
nss/nss_files/files-proto.c,
|
||
nss/nss_files/files-rpc.c,
|
||
nss/nss_files/files-service.c,
|
||
resolv/arpa/nameser_compat.h,
|
||
stdlib/gmp-impl.h,
|
||
string/strcoll_l.c,
|
||
sysdeps/unix/sysv/linux/clock_getres.c,
|
||
sysdeps/unix/sysv/linux/clock_gettime.c</samp></p>
|
||
|
||
<p><samp>elf/link.h</samp> には次のように function-like マクロの名前に置換される function-like マクロがあります。</p>
|
||
|
||
<pre>
|
||
#define ELFW(type) _ElfW (ELF, __ELF_NATIVE_CLASS, type)
|
||
/* sysdeps/generic/ldsodefs.h:46 */
|
||
#define _ElfW(e,w,t) _ElfW_1 (e, w, _##t) /* elf/link.h:32 */
|
||
#define _ElfW_1(e,w,t) e##w##t /* elf/link.h:33 */
|
||
#define __ELF_NATIVE_CLASS __WORDSIZE /* bits/elfclass.h:11 */
|
||
#define __WORDSIZE 32 /* sysdeps/wordsize-32/bits/wordsize.h:19 */
|
||
#define ELF32_ST_TYPE(val) ((val) & 0xf) /* elf/elf.h:429 */
|
||
</pre>
|
||
|
||
<p>上記のようなマクロ定義があると、</p>
|
||
|
||
<pre>
|
||
&& ELFW(ST_TYPE) (sym->st_info) != STT_TLS /* elf/do-lookup.h:81 */
|
||
</pre>
|
||
|
||
<p>このマクロ呼び出しでは <samp><tt>ELFW</tt>(ST_TYPE)</samp> が次のように展開されていきます。</p>
|
||
|
||
<pre>
|
||
ELFW(ST_TYPE)
|
||
_ElfW(ELF, __ELF_NATIVE_CLASS, ST_TYPE)
|
||
_ElfW_1(ELF, 32, _ST_TYPE)
|
||
ELF32_ST_TYPE
|
||
</pre>
|
||
|
||
<p>そして、<tt>ELF32_ST_TYPE</tt> がさらに <samp>(sym->st_info)</samp> を巻き込んで <samp>((sym->st_info) & 0xf)</samp> と展開されます。
|
||
すなわち、<samp><tt>_ElfW_1</tt>(ELF, 32, _ST_TYPE)</samp> という function-like macro の呼び出しが <tt>ELF32_ST_TYPE</tt> という別の function-like macro の名前に展開されるのです。</p>
|
||
|
||
<p>これは３つのマクロ定義を次のように書いて、</p>
|
||
|
||
<pre>
|
||
#define ELFW( type, val) _ElfW( ELF, __ELF_NATIVE_CLASS, type, val)
|
||
#define _ElfW( e, w, t, val) _ElfW_1( e, w, _##t, val)
|
||
#define _ElfW_1( e, w, t, val) e##w##t( val)
|
||
</pre>
|
||
|
||
<p>次のように呼び出したほうが、わかりやすくなります。
|
||
引数の渡し方が少し冗長に見えるかもしれませんが、関数呼び出しをモデルとして考えれば、こちらのほうが自然でしょう。</p>
|
||
|
||
<pre>
|
||
&& ELFW(ST_TYPE, sym->st_info) != STT_TLS
|
||
</pre>
|
||
|
||
<h4><a name="3.9.8.6">3.9.8.6. 'defined' に展開されるマクロ</a></h4>
|
||
|
||
<p>次のファイルには、置換リスト中に 'defined' というトークンの出てくるマクロの定義があります。*1</p>
|
||
|
||
<p><samp>iconv/skeleton.c,
|
||
sysdeps/generic/_G_config.h,
|
||
sysdeps/gnu/_G_config.h,
|
||
sysdeps/i386/dl-machine.h,
|
||
sysdeps/i386/i686/memset.S,
|
||
sysdeps/mach/hurd/_G_config.h,
|
||
sysdeps/posix/sysconf.c</samp></p>
|
||
|
||
<p>次のファイルではそれらのマクロが #if 行で使われています。
|
||
また、上記のファイル自身の中でも使われている場合があります。</p>
|
||
|
||
<p><samp>elf/dl-conflict.c,
|
||
elf/dl-runtime.c,
|
||
elf/dynamic-link.h</samp></p>
|
||
|
||
<p>glibc 2.1.3 の <samp>malloc/malloc.c</samp> には <tt>HAVE_MREMAP</tt> という、やはり置換リストに 'defined' が出てくるマクロがありましたが、glibc 2.4 ではこれは portable な形に直されています。
|
||
しかし、他のソースにこの種のマクロが増えてしまいました。</p>
|
||
<p>#if 行で置換リスト中に 'defined' が出てくるマクロ呼び出しの結果は規格では undefined であり、これを恣意的に処理するのは GCC の勝手仕様です。
|
||
他の処理系でも処理できる portable なソースにするためには、これらのマクロ定義を書き換えることが必要です。
|
||
時にはマクロ呼び出しも書き換えなければなりません。*2</p>
|
||
<p>この書き換えは多くの場合は、<a href="#3.9.4.6">3.9.4.6</a> にある方法でできます。
|
||
しかし、中にはこれでは対応できないものもあります。
|
||
<samp>'defined MACRO'</samp> の評価がタイミングによって異なる場合です。
|
||
例えば、<samp>sysdeps/i386/dl-machine.h</samp> には次のようなマクロ定義があり、このマクロが他のファイルの #if 式中で使われています。</p>
|
||
|
||
<pre>
|
||
#define ELF_MACHINE_NO_RELA defined RTLD_BOOTSTRAP
|
||
</pre>
|
||
|
||
<p>これをこう書き換えたのでは、うまくいきません。</p>
|
||
|
||
<pre>
|
||
#if defined RTLD_BOOTSTRAP
|
||
#define ELF_MACHINE_NO_RELA 1
|
||
#endif
|
||
</pre>
|
||
|
||
<p><samp>RTLD_BOOTSTRAP</samp> というマクロは <samp>elf/rtld.c</samp> で定義されますが、これが <samp>dl-machine.h</samp> より先に include される場合と後で include される場合があり、それによって <samp>'defined RTLD_BOOTSTRAP'</samp> の結果が違ってくるのです。
|
||
これを portable に書き直すには、<tt>ELF_MACHINE_NO_RELA</tt> というマクロを使うことをやめて、次のような #if 行を</p>
|
||
|
||
<pre>
|
||
#if ELF_MACHINE_NO_RELA
|
||
</pre>
|
||
|
||
<p>次のようにします。
|
||
<tt>ELF_MACHINE_NO_RELA</tt> は #if 行でしか使われていない無用なマクロなのです。</p>
|
||
|
||
<pre>
|
||
#if defined RTLD_BOOTSTRAP
|
||
</pre>
|
||
|
||
<p>glibc では実際にこの書き方になっているところも多くあるのですが、それが <tt>ELF_MACHINE_NO_RELA</tt> を使う undefined な書き方と混在しています。</p>
|
||
|
||
<p>注:</p>
|
||
<p>*1 Linux では /usr/include/_G_config.h は glibc の sysdeps/gnu/_G_config.h がインストールされたものなので、ここにも次のような同じマクロ定義がある。</p>
|
||
|
||
<pre>
|
||
#define _G_HAVE_ST_BLKSIZE defined (_STATBUF_ST_BLKSIZE)
|
||
</pre>
|
||
|
||
<p>これはこう書き換えておくべきである。</p>
|
||
|
||
<pre>
|
||
#if defined (_STATBUF_ST_BLKSIZE)
|
||
#define _G_HAVE_ST_BLKSIZE 1
|
||
#endif
|
||
</pre>
|
||
|
||
<p>*2 <b>mcpp</b> V.2.7 からは GCC-specific-build の <i>STD</i> モードに限って、#if 行のマクロに出てくる 'defined' トークンを GCC と同様に処理するようにした。
|
||
しかし、こうした bug-to-bug な対処をあてにすべきではない。</p>
|
||
|
||
<h4>3.9.8.7. .S ファイルの「プリプロセス」</h4>
|
||
|
||
<p>*.S ファイルは CPU ごとに用意されているのできわめて多く、1000 本あまりもあります（x86 等、１種類の CPU で使われるのはそのうちの一部）。</p>
|
||
<p>*.S ファイルはアセンブラソースに C の #if, #include 等の directive やコメントやマクロを混在させたものですが、アセンブラソースは C の token sequence の形をしていないので、これを C プリプロセッサで処理することには無理があります。
|
||
プリプロセッサは C で使わない %, $ 等の文字もそのまま通し、space の有無も原則としてそのまま維持しなければなりません。
|
||
さらに C ではエラーになるところをエラーにせずにそのまま通すように、文法チェックを大幅に緩和しなければなりません。
|
||
そして、その一方で #if やマクロは処理し、一応のエラーチェックもしなければならないのです。
|
||
やっかいなことです。
|
||
これらの仕様にはすべて論理的な根拠は何もなく、GCC の local な（多くは undocumented な）仕様を使っているにすぎません。</p>
|
||
<p>例えば <samp>nptl/sysdeps/unix/sysv/linux/i386/i486/pthread_cond_wait.S</samp> には次のような部分があります</p>
|
||
|
||
<pre>
|
||
.byte 8 # Return address register
|
||
# column.
|
||
#ifdef SHARED
|
||
.uleb128 7 # Augmentation value length.
|
||
.byte 0x9b # Personality: DW_EH_PE_pcrel
|
||
# + DW_EH_PE_sdata4
|
||
</pre>
|
||
|
||
<p><samp>'#ifdef SHARED'</samp> は C の directive ですが、各行の後半の # で始まる部分はコメントのつもりのようです。
|
||
しかし、<samp>'# column.'</samp> のように行の最初の non-white-space-character が # の場合は、無効な directive と構文上、区別がつきません。
|
||
<samp>'# + DW_EH_PE_sdata4'</samp> に至っては C では構文エラーになるものです。<br>
|
||
他のファイルには次のような例もあります。
|
||
ここで '\'' という文字は C では character constant の両端に使われるものなので、これが単独で現れると tokenization のエラーになります。</p>
|
||
|
||
<pre>
|
||
movl 12(%esp), %eax # that `fixup' takes its parameters in regs.
|
||
</pre>
|
||
|
||
<p>さらに、上記の pthread_cond_wait.S には次のような部分がありますが、これはマクロの呼び出しです。</p>
|
||
|
||
<pre>
|
||
versioned_symbol (libpthread, __pthread_cond_wait, pthread_cond_wait,
|
||
GLIBC_2_3_2)
|
||
</pre>
|
||
|
||
<p>このマクロの定義は次のようになっています。</p>
|
||
|
||
<pre>
|
||
# define versioned_symbol(lib, local, symbol, version) \
|
||
versioned_symbol_1 (local, symbol, VERSION_##lib##_##version)
|
||
/* include/shlib-compat.h:65 */
|
||
# define versioned_symbol_1(local, symbol, name) \
|
||
default_symbol_version (local, symbol, name)
|
||
/* include/shlib-compat.h:67 */
|
||
# define default_symbol_version(real, name, version) \
|
||
_default_symbol_version(real, name, version)
|
||
/* include/libc-symbols.h:398 */
|
||
# define _default_symbol_version(real, name, version) \
|
||
.symver real, name##@##@##version
|
||
/* include/libc-symbols.h:411 */
|
||
#define VERSION_libpthread_GLIBC_2_3_2 GLIBC_2.3.2
|
||
/* make で生成される abi-versions.h:145 */
|
||
</pre>
|
||
|
||
<p>これによって、このマクロはこういう展開結果になることが期待されています。</p>
|
||
|
||
<pre>
|
||
.symver __pthread_cond_wait, pthread_cond_wait@@GLIBC_2.3.2
|
||
</pre>
|
||
|
||
<p>問題は <tt>_default_symbol_version</tt> の定義です。
|
||
'@' という文字は C の token (pp-token) にはありません。
|
||
そして、これを ## 演算子で連結した <samp>pthread_cond_wait@@GLIBC_2.3.2</samp> という token もありません。
|
||
連結の途中にも illegal な token が生成されます。
|
||
このマクロは C の ## 演算子を使っていますが、文法は C とは掛け離れたものです。</p>
|
||
<p>アセンブラソースについてプリプロセスのようなことをするのであれば、やはりアセンブラ用のマクロプロセッサを使うべきでしょう。
|
||
C プリプロセッサを使うのであれば、*.S ではなく *.c として、アセンブラ用のコードは文字列リテラルに埋め込んで asm() なり __asm__() なりの関数に渡すべきでしょう。
|
||
<samp>libc-symbols.h</samp> には次のような別バージョンのマクロも用意されていて、*.c であればこちらが使われます。
|
||
こちらは規格準拠の C プリプロセッサで問題なく処理できます。</p>
|
||
|
||
<pre>
|
||
# define _default_symbol_version(real, name, version) \
|
||
__asm__ (".symver " #real "," #name "@@" #version)
|
||
</pre>
|
||
|
||
<p>glibc には asm() や __asm()__ を使った *.c, *.h ファイルも多くありますが、まだ過半は変則的な *.S ファイルとなっています。</p>
|
||
<p>どうしてもアセンブラソースを C プリプロセッサで処理するのであれば、せめてコメント記号としては # ではなく /* */ か // を使うべきです。
|
||
実際、glibc でも /* */ か // を使っているソースが多いのですが、# を使っているソースもいくつかあります。</p>
|
||
<p>とは言え、glibc 2.4 では *.S ファイルがあまりにも多く、しかも 2.1.3 のころよりも C の文法を無視したソースが多くなっているので、<b>mcpp</b> では V.2.6.3 から lang-asm モードでの文法チェックを大幅に緩和し、これらの変則ソースが処理できるようにしました。</p>
|
||
|
||
<h4>3.9.8.8. versions.awk, rpcgen と -dM オプションの仕様の問題</h4>
|
||
|
||
<p><a href="#3.9.4.8">3.9.4.8</a> に書いた <samp>stdlib/isomac.c</samp> の問題は変わっていません。</p>
|
||
<p>rpcgen の問題も変わっていません。</p>
|
||
<p>さらに glibc 2.4 には <samp>scripts/versions.awk</samp> というファイルがありますが、これはプリプロセッサの出力の行頭の space の数について、GCC でしか通用しない仮定を持ち込んでいます。
|
||
<b>mcpp</b> や他のプリプロセッサを使うためには、このファイルを次のように修正しなければなりません。</p>
|
||
|
||
<pre>
|
||
$ diff -c versions.awk*
|
||
*** versions.awk 2006-12-13 00:59:56.000000000 +0900
|
||
--- versions.awk.orig 2005-03-23 10:46:29.000000000 +0900
|
||
***************
|
||
*** 50,56 ****
|
||
}
|
||
|
||
# This matches the beginning of a new version for the current library.
|
||
! /^ *[A-Z]/ {
|
||
if (renamed[actlib "::" $1])
|
||
actver = renamed[actlib "::" $1];
|
||
else if (!versions[actlib "::" $1] && $1 != "GLIBC_PRIVATE") {
|
||
--- 50,56 ----
|
||
}
|
||
|
||
# This matches the beginning of a new version for the current library.
|
||
! /^ [A-Za-z_]/ {
|
||
if (renamed[actlib "::" $1])
|
||
actver = renamed[actlib "::" $1];
|
||
else if (!versions[actlib "::" $1] && $1 != "GLIBC_PRIVATE") {
|
||
***************
|
||
*** 65,71 ****
|
||
# This matches lines with names to be added to the current version in the
|
||
# current library. This is the only place where we print something to
|
||
# the intermediate file.
|
||
! /^ *[a-z_]/ {
|
||
sortver=actver
|
||
# Ensure GLIBC_ versions come always first
|
||
sub(/^GLIBC_/," GLIBC_",sortver)
|
||
--- 65,71 ----
|
||
# This matches lines with names to be added to the current version in the
|
||
# current library. This is the only place where we print something to
|
||
# the intermediate file.
|
||
! /^ / {
|
||
sortver=actver
|
||
# Ensure GLIBC_ versions come always first
|
||
sub(/^GLIBC_/," GLIBC_",sortver)
|
||
</pre>
|
||
|
||
<h4>3.9.8.9. -include, -isystem, -I- オプション</h4>
|
||
|
||
<p><samp>-isystem, -I-</samp> オプションは使われていません。</p>
|
||
<p>しかし、<samp>-include</samp> オプションは極端に頻繁に使われています。
|
||
<samp>include/libc-symbols.h</samp> というヘッダファイルが <samp>-include</samp> オプションによって 7000 回も include されるのです。
|
||
このオプションは、本来はソース中に <samp>#include</samp> で書くべき行を makefile に押し出して使うためのものです。
|
||
ソースを不完全にするので、決して良いことではありません。</p>
|
||
|
||
<h4>3.9.8.10. Undocumented な事前定義マクロ</h4>
|
||
|
||
<p>これは glibc の問題ではなく、GCC の問題です。
|
||
GCC 2 ではいくつかの重要な事前定義マクロが undocumented でしたが、その状態は GCC 3 で解消されました。
|
||
しかし、他方で GCC 3.3 からは事前定義マクロが極端に増えたのに伴って、undocumented なものが大幅に増えてしまいました。</p>
|
||
|
||
<h4>3.9.8.11. その他の問題</h4>
|
||
|
||
<p><samp>debug/tst-chk1.c</samp> には奇妙な部分があり、次のように修正しないと GCC 以外のプリプロセッサでは意図通りに処理されません。</p>
|
||
|
||
<pre>
|
||
$ diff -cw tst-chk1.c*
|
||
*** tst-chk1.c 2007-01-11 00:31:45.000000000 +0900
|
||
--- tst-chk1.c.orig 2005-08-23 00:12:34.000000000 +0900
|
||
***************
|
||
*** 113,119 ****
|
||
static int
|
||
do_test (void)
|
||
{
|
||
- int arg;
|
||
struct sigaction sa;
|
||
sa.sa_handler = handler;
|
||
sa.sa_flags = 0;
|
||
--- 113,118 ----
|
||
***************
|
||
*** 135,146 ****
|
||
struct A { char buf1[9]; char buf2[1]; } a;
|
||
struct wA { wchar_t buf1[9]; wchar_t buf2[1]; } wa;
|
||
|
||
#ifdef __USE_FORTIFY_LEVEL
|
||
! arg = (int) __USE_FORTIFY_LEVEL;
|
||
#else
|
||
! arg = 0;
|
||
#endif
|
||
! printf ("Test checking routines at fortify level %d\n", arg);
|
||
|
||
/* These ops can be done without runtime checking of object size. */
|
||
memcpy (buf, "abcdefghij", 10);
|
||
--- 134,146 ----
|
||
struct A { char buf1[9]; char buf2[1]; } a;
|
||
struct wA { wchar_t buf1[9]; wchar_t buf2[1]; } wa;
|
||
|
||
+ printf ("Test checking routines at fortify level %d\n",
|
||
#ifdef __USE_FORTIFY_LEVEL
|
||
! (int) __USE_FORTIFY_LEVEL
|
||
#else
|
||
! 0
|
||
#endif
|
||
! );
|
||
|
||
/* These ops can be done without runtime checking of object size. */
|
||
memcpy (buf, "abcdefghij", 10);
|
||
</pre>
|
||
|
||
<p>この元ソースは何の変哲もない書き方に見えますが、実はここでは printf() がマクロとして定義されているのです。
|
||
そのため、<samp>#ifdef</samp> 等のディレクティブ行らしきものが通常はマクロの引数として扱われる結果になります。
|
||
マクロ呼び出しの中でなければディレクティブ行となるものが引数中に現れた場合の結果は、規格では undefined です。
|
||
ディレクティブの処理とマクロ展開は同じ translation phase で行われるので、ディレクティブを先に処理するのは、GCC の勝手仕様です。
|
||
そもそも、<samp>#ifdef __USE_FORTIFY_LEVEL</samp> の処理にもマクロの処理が必要なので、この行を先に処理してから printf() マクロを展開するというのは、きわめて恣意的な処理です。
|
||
C プリプロセスというものは、頭から sequentially に処理してゆくべきものなのです。</p>
|
||
|
||
<p>glibc を configure するときにも、GCC の特殊な help message を使う部分があります。
|
||
Help に <samp>"-z relro"</samp> というオプションが出てくるかどうかをサーチするものです。
|
||
プリプロセッサに <b>mcpp</b> を使っていると、これは期待する結果にはなりません。
|
||
しかし、それでも glibc のコンパイルとテストは正常に行われます。</p>
|
||
|
||
<p>なお、GCC 3.2 までは gcc を起動すると無用な -A オプションがいろいろとデフォルトで付加されましたが、GCC 3.3 からはなくなりました。</p>
|
||
|
||
<h4>3.9.8.12. 深まる GCC 依存</h4>
|
||
|
||
<p>glibc 2.4 を６年前の glibc 2.1.3 と比べると、私がかつて取り上げた portability の問題はほとんど改善されておらず、逆に portability を欠いたソースが増えてきていることがわかります。</p>
|
||
<p>改善されたのは、行をまたぐ文字列リテラルがなくなったこと、<samp>-isystem, -I-</samp> オプションが使われなくなったこと、GCC の側で <samp>-A</samp> オプションが使われなくなったことくらいです。</p>
|
||
<p>#include_next、GCC2 仕様の可変引数マクロ、中でも可変引数が 0 個のマクロ呼び出し、置換リストに 'defined' のあるマクロ、*.S ファイル、<samp>-include</samp> オプション、これらは大幅に増えました。マクロ呼び出しのカラ引数も増えました。
|
||
Portable なソースに書き直すことが簡単にはできない、Standard C と１対１に対応しない書き方が増えたのも、やっかいなところです。</p>
|
||
<p>これらの問題はすべて GCC の local な仕様への依存によるものです。
|
||
GCC の undocumented な動作に依存している部分も多くあります。
|
||
大規模なソフトウェアでそうした部分が発生すると、多くのソースファイルが絡み合うため、修正が困難になり、何年でも同じ書き方が継承されてゆくことになりがちです。
|
||
そして、新しいソースもそれに合わせて書かれることになります。
|
||
可変引数マクロは GCC2 仕様のものだけで、C99 の仕様のものはおろか GCC3 仕様のものさえ使われていないことは、この関係を端的に表しています。
|
||
また、せっかく一部のソースの unportable な部分が書き直されても、他のソースに古い書き方が新たに現れる場合も多く、なかなか整理されません。</p>
|
||
<p>逆に GCC のほうも仕様の変更は大きな影響をもたらすので、簡単にはできなくなってしまいます。
|
||
どこかで双方の思い切った整理が必要だと思われます。</p>
|
||
|
||
<h3><a name="3.9.9" href="#toc.3.9.9">3.9.9. Linux の stddef.h, limits.h, #include_next の問題</a></h3>
|
||
<p>Linux では GCC がシステムコンパイラである上にライブラリが glibc であるため、システムヘッダには GCC しか想定していない部分がところどころにあります。
|
||
これが compiler-independent-build の <b>mcpp</b> のような他の処理系を使う場合の障害になります。
|
||
中でも <samp>stddef.h</samp> 等のいくつかの標準ヘッダファイルが GCC の version-specific な include directory にだけあって <samp>/usr/include</samp> に存在しないというのはお粗末な欠陥であり、<b>mcpp</b> にとっては対策が必要です。
|
||
このセクションではこの問題を検討します。</p>
|
||
<p>Linux では GCC のバージョンごとに例えば <samp>/usr/lib/gcc-lib/SYSTEM/VERSION/include</samp> といった include directory がシステムに追加されますが、そこにある stddef.h, limits.h 等は奇妙なものです。
|
||
CygWIN でも同じです。
|
||
Mac OS X にも少し問題があります。</p>
|
||
|
||
<h4>3.9.9.1. /usr/include に標準ヘッダがない</h4>
|
||
<p>まず、C の標準ヘッダファイルのうち <samp>float.h, iso646.h, stdarg.h, stdbool.h, stddef.h</samp> の５つは Linux ではこの GCC のディレクトリにだけあり、<samp>/usr/include</samp> にも <samp>/usr/local/include</samp> にも存在しません。Linux のシステムヘッダは処理系が GCC であれば GCC 固有の include directory も使い、GCC でなければ <samp>/usr/include</samp> だけを使うように一応書かれているようですが、stddef.h 等がないのでは困ります。</p>
|
||
<p>かといって、GCC 以外の処理系で GCC 固有の include directory を使うようにすると、今度はこのディレクトリにある limits.h で GCC 固有の拡張仕様である #include_next にぶつかります。たとえ #include_next を実装しても、今度は limits.h の書き方がおかしいために問題が起こります。ことに GCC V.3.3 以降では limits.h で定義すべき定数を事実上、処理系で事前定義するという乱暴なことをやるようになったため、他の処理系では limits.h が使えないという結果になってしまいます。</p>
|
||
<p>また、GCC 自身も、この limits.h の #include_next では不可解な動作をします。</p>
|
||
<p>この問題は説明するとややこしいのですが、なぜか何年ものあいだ放置されている問題なので、ここにまとめておきます。</p>
|
||
<p>なお、これは compiler-independent-build の <b>mcpp</b> で問題になるものです。
|
||
GCC-specific-build では問題は発生しません。</p>
|
||
|
||
<h4>3.9.9.2. #include_next の奇妙な処理</h4>
|
||
<p>GCC では include directory は通常は次のようになります。</p>
|
||
<pre>
|
||
/usr/local/include
|
||
/usr/lib/gcc-lib/SYSTEM/VERSION/include
|
||
/usr/include
|
||
</pre>
|
||
<p>これらのディレクトリが上から下へサーチされます。
|
||
この２番目が GCC 固有の include directory です。この SYSTEM は例えば i386-vine-linux, i386-redhat-linux、VERSION は 3.3.2, 3.4.3 等となります。GCC の別のバージョンを <samp>/usr/local</samp> に追加インストールした場合はこの <samp>/usr/lib/gcc-lib</samp> は <samp>/usr/local/lib/gcc</samp> となります。C++ では <samp>/usr/local/include</samp> の前にさらにいくつかのディレクトリが加わります。GCC V.3.*, 4.* では次のものです。</p>
|
||
<pre>
|
||
/usr/include/c++/VERSION
|
||
/usr/include/c++/VERSION/SYSTEM
|
||
/usr/include/c++/VERSION/backward
|
||
</pre>
|
||
<p>これらのディレクトリの名前は GCC 固有のものに見えますが、C++ の標準ディレクトリはほかに存在しないので、他の処理系も <samp>/usr/include/c++/VERSION</samp> を使うしかありません。GCC V.2.95 では C++ の include directory は次のものでした。</p>
|
||
<pre>
|
||
/usr/include/g++-3
|
||
</pre>
|
||
<p>さらに -I オプションや環境変数で指定されたディレクトリが、このリストの前に追加されます。</p>
|
||
<p>以下では説明をわかりやすくするために GCC V.3.3 以降での C の limits.h に話を限ります。中でも <tt>LONG_MAX</tt> の定義を例にとります。limits.h は <samp>/usr/include</samp> と GCC 専用ディレクトリの２個所にあります。</p>
|
||
<pre>
|
||
#include <limits.h>
|
||
</pre>
|
||
<p>この行があると GCC は <samp>/usr/lib/gcc-lib/SYSTEM/VERSION/include/limits.h</samp> を include します。すると、このファイルの冒頭は</p>
|
||
<pre>
|
||
#ifndef _GCC_LIMITS_H_
|
||
#define _GCC_LIMITS_H_
|
||
#ifndef _LIBC_LIMITS_H_
|
||
#include "syslimits.h"
|
||
#endif
|
||
</pre>
|
||
<p>となっているので、<samp>/usr/lib/gcc-lib/SYSTEM/VERSION/include/syslimits.h</samp> が include されます。このファイルは次のような短いものです。</p>
|
||
<pre>
|
||
#define _GCC_NEXT_LIMITS_H
|
||
#include_next <limits.h>
|
||
#undef _GCC_NEXT_LIMITS_H
|
||
</pre>
|
||
<p>さて、ここで limits.h が再び include されますが、#include_next なので <samp>/usr/lib/gcc-lib/SYSTEM/VERSION/include</samp> をスキップして <samp>/usr/include</samp> がサーチされるはずです。GCC の cpp.info には次のように書いてあります。</p>
|
||
<blockquote>This directive works like `#include' except in searching for the specified file: it starts searching the list of header file directories _after_ the directory in which the current file was found.</blockquote>
|
||
<p>ところが GCC はなぜか <samp>/usr/include/limits.h</samp> ではなく <samp>/usr/lib/gcc-lib/SYSTEM/VERSION/include/limits.h</samp> をもう一度 include してしまいます。<br>
|
||
今度は <tt>_GCC_LIMITS_H_</tt> が定義されている状態なので</p>
|
||
<pre>
|
||
#ifndef _GCC_LIMITS_H_
|
||
</pre>
|
||
<p>以下のブロックはスキップされ、次のブロックが評価されます。</p>
|
||
<pre>
|
||
#else
|
||
#ifdef _GCC_NEXT_LIMITS_H
|
||
#include_next <limits.h>
|
||
#endif
|
||
#endif
|
||
</pre>
|
||
<p>またしても <samp>/usr/lib/gcc-lib/SYSTEM/VERSION/include/syslimits.h</samp> にあったのとまったく同じ #include_next <limits.h> という行です。また <samp>/usr/lib/gcc-lib/SYSTEM/VERSION/include/limits.h</samp> が、すなわち自分自身が include されるのかと思うと、今度は GCC は <samp>/usr/include/limits.h</samp> を include するのです。GCC の #include_next の動作は一向にわかりません。</p>
|
||
<p><samp>/usr/include/limits.h</samp> では <features.h> 等が include されます。また、次の行で始まるブロックがあります。</p>
|
||
<pre>
|
||
#if !defined __GNUC__ || __GNUC__ < 2
|
||
</pre>
|
||
<p>このブロックでは <bits/wordsize.h> を include した上で、wordsize が 32 ビットであるか 64 ビットであるかに応じて規格で要求されている各種定数を定義するようになっています。たとえば 32 ビットであれば <tt>LONG_MAX</tt> は次のように定義されます。</p>
|
||
<pre>
|
||
#define LONG_MAX 2147483647L
|
||
</pre>
|
||
<p>しかし、GCC ではこのブロックは当然スキップされます。そして、このファイルが終わり、include 元の <samp>/usr/lib/gcc-lib/SYSTEM/VERSION/include/limits.h</samp> に戻ります。このファイルもこれで２度目の include を終わり、<samp>/usr/lib/gcc-lib/SYSTEM/VERSION/include/syslimits.h</samp> に戻り、このファイルもこれで終わって <samp>/usr/lib/gcc-lib/SYSTEM/VERSION/limits.h</samp> の最初の include に戻ります。このファイルは上記の部分のあとに各種定数の定義があります。<tt>LONG_MAX</tt> については次のようになっています。</p>
|
||
<pre>
|
||
#undef LONG_MAX
|
||
#define LONG_MAX __LONG_MAX__
|
||
</pre>
|
||
<p>これでこのファイルも終わります。</p>
|
||
<pre>
|
||
#include <limits.h>
|
||
</pre>
|
||
<p>の処理はこれですべて終わりです。
|
||
結局、<tt>LONG_MAX</tt> は <tt>__LONG_MAX__</tt> と定義されてオシマイなのです。<tt>__LONG_MAX__</tt> とはいったい何なのでしょうか。実は GCC V.3.3 以降では <tt>__LONG_MAX__</tt> やその他の多くのマクロが事前定義されているのです。32 ビットシステムでは <tt>__LONG_MAX__</tt> は 2147483647L と事前定義されています。<tt>LONG_MAX</tt> 以外の規格で要求されている各種マクロについても、事前定義されたマクロを元に定義されているので、事情は大同小異です。それなら、このややこしいヘッダファイルと #include_next の処理はいったい何のためなのでしょうか？</p>
|
||
<p>#include_next の動作は GCC V.2.95.3, V.3.2, V.3.4, V.4.0, V.4.1 でも V.3.3 と同じです。すなわち、</p>
|
||
<pre>
|
||
#include_next <limits.h>
|
||
</pre>
|
||
<p>で <samp>/usr/lib/gcc-lib/SYSTEM/VERSION/include/syslimits.h</samp> から <samp>/usr/lib/gcc-lib/SYSTEM/VERSION/include/limits.h</samp> が include され、そこにある同じ</p>
|
||
<pre>
|
||
#include_next <limits.h>
|
||
</pre>
|
||
<p>で <samp>/usr/include/limits.h</samp> が include されます。</p>
|
||
<pre>
|
||
#include <limits.h>
|
||
</pre>
|
||
<p>では <samp>/usr/lib/gcc-lib/SYSTEM/VERSION/include/limits.h</samp> が２回 include されることになります。このファイルを２回 include しても結果は変りませんが、ムダであり、何より仕様と動作が違っており、動作が一貫していません。このファイルの次のブロックも本来はムダな部分です。</p>
|
||
<pre>
|
||
#else
|
||
#ifdef _GCC_NEXT_LIMITS_H
|
||
#include_next <limits.h>
|
||
#endif
|
||
</pre>
|
||
|
||
<h4>3.9.9.3. GCC でないと標準ヘッダを使えない</h4>
|
||
<p>では次に GCC 以外の処理系で Linux のシステムヘッダを使うとどうなるでしょうか？ GCC 固有の include directory を使わないと、stddef.h 等が見つかりません。それなら GCC の include directory を使うとどうなるでしょうか？ stddef.h は見つかりますが、今度は limits.h がおかしくなります。</p>
|
||
<pre>
|
||
#include <limits.h>
|
||
</pre>
|
||
<p>この行でプリプロセッサは <samp>/usr/lib/gcc-lib/SYSTEM/VERSION/include/limits.h</samp> を include します。そこから <samp>/usr/lib/gcc-lib/SYSTEM/VERSION/include/syslimits.h</samp> が include されます。そして、</p>
|
||
<pre>
|
||
#include_next <limits.h>
|
||
</pre>
|
||
<p>でエラーになります。</p>
|
||
<p>では、プリプロセッサが #include_next を実装したらどうなるでしょうか？ #include_next が仕様通りに実装されていれば、ここで <samp>/usr/include/limits.h</samp> が include されます。そして、上記の</p>
|
||
<pre>
|
||
#if !defined __GNUC__ || __GNUC__ < 2
|
||
</pre>
|
||
<p>以下のブロックが処理され、<tt>LONG_MAX</tt> が次のように定義され、その他のマクロも適切な定数に定義されます。</p>
|
||
<pre>
|
||
#define LONG_MAX 2147483647L
|
||
</pre>
|
||
<p>そして、include 元の <samp>/usr/lib/gcc-lib/SYSTEM/VERSION/syslimits.h</samp> に戻り、このファイルが終わって <samp>/usr/lib/gcc-lib/SYSTEM/VERSION/limits.h</samp> に戻ります。すると、何と</p>
|
||
<pre>
|
||
#undef LONG_MAX
|
||
#define LONG_MAX __LONG_MAX__
|
||
</pre>
|
||
<p>これでいったん正しく定義されたマクロはすべてご破算にされて <samp>__LONG_MAX__</samp> 等という未定義の名前になってしまうのです！</p>
|
||
<p>GCC V.3.2 までなら、これでもまだ</p>
|
||
<pre>
|
||
#define __LONG_MAX__ 2147483647L
|
||
</pre>
|
||
<p>という行があったので、
|
||
ご破算にされてももう一度、正しく定義し直されました。途中はムダな処理ですが、結果は正しいので使うことができました。しかし、V.3.3 以降のヘッダファイルではすべては徒労に終わります。</p>
|
||
|
||
<h4>3.9.9.4. 当面の対策</h4>
|
||
<p>以上をまとめると、問題は次の点にあります。*1, *2, *3, *4</p>
|
||
<ol>
|
||
<li>Linux のシステムヘッダを GCC 専用にしないためには <samp>/usr/include</samp> に <samp>float.h, iso646.h, stdarg.h, stdbool.h, stddef.h</samp> が必要であるが、これがない。<br>
|
||
<li>C++ の標準 include directory を GCC のバージョン依存にしないためには、<samp>/usr/include/c++/VERSION</samp> ではなく <samp>/usr/include/c++</samp> を使ってもらいたいものである。<samp>/usr/include/c++/VERSION/*</samp> は GCC 固有のものに限るべきである。
|
||
FreeBSD, Linux, Mac OS X ではすべて C++ の standard library は GCC の libstdc++ なので、対処しにくいことであるが。<br>
|
||
<li>GCC の #include_next の動作は仕様と異なっており、かつ一貫性がない。<br>
|
||
<li>GCC が <limits.h> で定義するマクロを事実上自前で事前定義するのでは、ややこしいヘッダファイルの処理をする意味がない。<samp>/usr/lib/gcc-lib/SYSTEM/VERSION/include/limits.h</samp> ですべてを #undef するのではなおさらムダである。少なくとも Linux や CygWIN では limits.h を２つに分ける必要はないはずである。このディレクトリのヘッダファイルは GCC をインストールする時に自動生成されるものなので、ある程度の冗長性はやむをえないであろうが、それにしてもシステム・ヘッダとしてインストールするには汚すぎる。<br>
|
||
</ol>
|
||
<p>これらの問題の根元にあるのはシステムヘッダの構成の過剰な複雑さです。そして、#include_next という拡張ディレクティブが混乱に輪をかけています。このディレクティブの用途はごく限られており、GCC や glibc のコンパイルとインストールで使われているものの、インストールされたシステムヘッダでは limits.h にあるだけです。その limits.h の処理がこう混乱しているのでは、その存在理由が疑われます。</p>
|
||
<p>さて、Linux および CygWIN 上の <b>mcpp</b> の compiler-independent 版では以上の問題に対処するため、とりあえずは次のように設定する必要があります。Compiler-independent 版では混乱を避けるため、#include_next は実装しません。GCC 固有の include directory も組み込みません。</p>
|
||
<ol>
|
||
<li><samp>/usr/include/stddef.h</samp> を <samp>/usr/lib/gcc-lib/SYSTEM/VERSION/include/stddef.h</samp> へのリンクとして作成しておく。複数の GCC のバージョンがインストールされている場合もそのどれかにリンクしておけば、Linux, CygWIN 上で compiler-independent で使う分には問題ないと思われる。これは GCC にも、GCC 専用版の <b>mcpp</b> にも悪影響は与えない。stdarg.h も同様である。マクロが GCC の組み込み関数に展開されるが、単にプリプロセスするだけならそれでもすむ。<br>
|
||
<li>iso646.h, stdbool.h はごく簡単なものであり、処理系やシステムに依存するものではないので、GCC のどれかのバージョンのものを <samp>/usr/include</samp> にコピーするか移動すればすむ。limits.h は GCC 以外の処理系では <samp>/usr/include</samp> のものだけで十分である。<br>
|
||
<li>float.h は <tt>DBL_MAX_EXP</tt> が <samp>__DBL_MAX_EXP__</samp> に定義されるといった内容なので、他のプリプロセッサには役に立たない。必要なら GCC の内部設定などを参考に書く。*5<br>
|
||
<li>GCC 固有の C の include directory は環境変数では設定しない。<br>
|
||
<li>環境変数 CPLUS_INCLUDE で <samp>/usr/include/c++/VERSION:/usr/include/c++/VERSION/SYSTEM:/usr/include/c++/VERSION/backward</samp> を C++ の include directory として設定する。<br>
|
||
</ol>
|
||
<p>GCC 専用版の <b>mcpp</b> では GCC 固有の include directory を組み込み、#include_next も仕様通りに実装し、互換のための事前定義マクロも定義するので、特別な設定は必要ありません。</p>
|
||
<p>注:</p>
|
||
<p>*1 この 3.9.9 の記載は Linux / GCC 2.95.3, 3.2, 3.3.2, 3.4.3, 4.0.2, 4.1.1, 4.3.0 および CygWIN / GCC 2.95.3, 3.4.4 で確認したものである。
|
||
CygWIN / GCC 2.95.3 では #include_next の動作は仕様通りであったが、3.4.4 では Linux と同じになった。
|
||
また、CygWIN の C++ の include directory は 2.95.3 では <samp>/usr/include/g++-3</samp> であったが、3.4.4 では <samp>/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++</samp> 以下となっている。</p>
|
||
<p>*2 FreeBSD 6.2, 6.3 / GCC 3.4.6 では <samp>/usr/include</samp> に C のすべての標準ヘッダがあり、GCC 固有の include directory も C では存在しない。
|
||
#include_next もシステムヘッダには無い。
|
||
ただ、C++ の include directory は <samp>/usr/include/c++/3.4, /usr/include/c++/3.4/backward</samp> と GCC のバージョン依存となっている。<br>
|
||
FreeBSD でも別バージョンの GCC をインストールすると GCC-version-specific な include directory が作られる。
|
||
そこにできるヘッダファイルの多くはムダなものである。
|
||
しかし、<samp>/usr/include</samp> のヘッダファイルが書き換えられることはない。</p>
|
||
<p>*3 Mac OS X Leopard / Apple-GCC 4.0.1 では GCC の version-specific な include directory は Linux と同様である。
|
||
#include_next も <samp>limits.h</samp> 等で使われている。
|
||
<samp>limits.h</samp> の構成も Linux と同様であるが、ただし <samp>syslimits.h</samp> の #include_next は削除されている。
|
||
また、<samp>float.h, iso646.h, stdarg.h, stdbool.h, stddef.h</samp> はすべて <samp>/usr/include</samp> にあるので、<b>mcpp</b> の側での対策はあまり必要ない。
|
||
しかし、<samp>float.h, stdarg.h</samp> は GCC 用と Metrowerks (for powerpc) 用なので、<b>mcpp</b> で使うなら <samp>stdarg.h</samp> は GCC の version-specific なディレクトリ中のヘッダを include するようにディレクティブを書き足し、<samp>float.h</samp> ではマクロを書き足しておかなければならない。
|
||
<samp>float.h</samp> は x86 と powerpc とでいくつかの値が異なることに注意。</p>
|
||
<p>*4 MinGW / GCC 3.4.* では include directories とその優先順位が他のシステムと異なるが、GCC の #include_next の動作は同じであり、また標準の include directory である <samp>/mingw/include</samp> にいくつかの標準ヘッダがなくて version-specific-directory にある点も CygWIN 等と同じである。</p>
|
||
<p>*5 GCC の設定を参照して i386 版の float.h を書けば、次のようになる。</p>
|
||
<pre>
|
||
/* float.h */
|
||
|
||
#ifndef _FLOAT_H___
|
||
#define _FLOAT_H___
|
||
|
||
#define FLT_ROUNDS 1
|
||
#define FLT_RADIX 2
|
||
|
||
#define FLT_MANT_DIG 24
|
||
#define DBL_MANT_DIG 53
|
||
#define LDBL_MANT_DIG 64
|
||
|
||
#define FLT_DIG 6
|
||
#define DBL_DIG 15
|
||
#define LDBL_DIG 18
|
||
|
||
#define FLT_MIN_EXP (-125)
|
||
#define DBL_MIN_EXP (-1021)
|
||
#define LDBL_MIN_EXP (-16381)
|
||
|
||
#define FLT_MIN_10_EXP (-37)
|
||
#define DBL_MIN_10_EXP (-307)
|
||
#define LDBL_MIN_10_EXP (-4931)
|
||
|
||
#define FLT_MAX_EXP 128
|
||
#define DBL_MAX_EXP 1024
|
||
#define LDBL_MAX_EXP 16384
|
||
|
||
#define FLT_MAX_10_EXP 38
|
||
#define DBL_MAX_10_EXP 308
|
||
#define LDBL_MAX_10_EXP 4932
|
||
|
||
#define FLT_MAX 3.40282347e+38F
|
||
#define DBL_MAX 1.7976931348623157e+308
|
||
#define LDBL_MAX 1.18973149535723176502e+4932L
|
||
|
||
#define FLT_EPSILON 1.19209290e-7F
|
||
#define DBL_EPSILON 2.2204460492503131e-16
|
||
#define LDBL_EPSILON 1.08420217248550443401e-19L
|
||
|
||
#define FLT_MIN 1.17549435e-38F
|
||
#define DBL_MIN 2.2250738585072014e-308
|
||
#define LDBL_MIN 3.36210314311209350626e-4932L
|
||
|
||
#if defined (__STDC_VERSION__) && __STDC_VERSION__ >= 199901L
|
||
#define FLT_EVAL_METHOD 2
|
||
#define DECIMAL_DIG 21
|
||
#endif /* C99 */
|
||
|
||
#endif /* _FLOAT_H___ */
|
||
</pre>
|
||
<br>
|
||
|
||
<h3><a name="3.9.10" href="#toc.3.9.10">3.9.10. Mac OS X / Apple-GCC とシステムヘッダの問題</a></h3>
|
||
<p><b>mcpp</b> は V.2.7 から Mac OS X / GCC もサポートするようになりましたが、このシステムの問題点を以下にまとめておきます。
|
||
ただ、筆者はまだこのシステムではほとんど <b>mcpp</b> と firefox くらいしかコンパイルしていないので、知らない部分が多くあります。
|
||
ことに Objective C / Objective C++ についてはまったく知りません。</p>
|
||
<p>この OS は GCC がほとんど唯一のコンパイラとなっているため、そのシステムヘッダには GCC-local な仕様への依存が一部に見られます。
|
||
ライブラリが glibc ではないせいか、その程度は Linux ほどではありません。
|
||
しかし、FreeBSD よりは多いようです。
|
||
もう少し整理できるはずだと思われます。</p>
|
||
<p>このシステムのもう１つの特徴は Apple によってかなり手を加えられた GCC がシステムコンパイラとなっていることです。
|
||
Mac OS X のシステムヘッダや Apple のソースでは、一般の GCC-local な仕様よりもむしろ Apple-GCC-local な仕様への依存のほうが目立ちます。
|
||
中でも、Intel-Mac と PowerPC-Mac の双方を１つのマシンでサポートするための拡張仕様が特徴的です。</p>
|
||
<p>なお、ここで取り上げるのは Mac OS X Leopard / Apple-GCC 4.0.1 です。</p>
|
||
|
||
<h4>3.9.10.1. #include_next, #warning</h4>
|
||
<p>GCC-local な仕様である #include_next は多くはありませんが、<samp>/usr/include/</samp> の <samp>float.h, stdarg.h, varargs.h</samp> および <samp>/Developer/SDKs/MacOSX10.*.sdk/usr/include/</samp> の同名のファイルで使われています。
|
||
それらはいずれもコンパイラが GCC であるか Metrowerks であるかによって include されるヘッダファイルを振り分けるためのものです。
|
||
GCC だと <samp>stdarg.h</samp> 等の同名のヘッダファイルが #include_next されるようになっています。<br>
|
||
また、Linux と同様に、GCC の version-specific な include directory では <samp>limits.h</samp> に #include_next がありますが、<samp>syslimits.h</samp> のものは削除されて、少しだけ整理されています。</p>
|
||
<p>このディレクティブは控え目に使われていますが、<samp>float.h, stdarg.h</samp> が GCC と Metrowerks しか想定していないのは問題です。
|
||
FreeBSD と同じところまで portable に書くことはできるはずです。*1<br>
|
||
また、<samp>/usr/include</samp> 内のヘッダファイルで GCC 用に #include_next を書くのはナンセンスです。
|
||
GCC ではこのディレクトリのほうが version-specific な include directory より優先順位が低いからです。
|
||
したがって、この #include_next は決して実行されることはありません。</p>
|
||
<p>#warning は <samp>/usr/include/</samp> の <samp>objc/, wx-2.8/wx/</samp> 等のディレクトリやそれに対応する <samp>/Developer/SDKs/MacOSX*.sdk/usr/include/</samp> 内のディレクトリに時々見られます。
|
||
多くは obsolete ないし deprecated な使い方やファイルに関するウォーニングのようです。<br>
|
||
<samp>/usr/include/c++/VERSION/backward/</samp> およびそれに対応する <samp>/Developer/SDKs/MacOSX*.sdk/</samp> 内の <samp>backward_warning.h</samp> はやはり deprecated なヘッダを使うなという #warning を実行するためのファイルですが、このディレクトリ内のヘッダファイルはすべてこのファイルを include するようになっています。
|
||
これは Linux や FreeBSD と同じです。</p>
|
||
<p>注:</p>
|
||
<p>*1 <b>mcpp</b> の compiler-independent-build でこれらのヘッダを使う方法については、3.9.9.4 およびその注 3 を参照。</p>
|
||
|
||
<h4>3.9.10.2. 'defined' に展開されるマクロ</h4>
|
||
<p><samp>/usr/include/sys/cdefs.h</samp> およびそれに対応する <samp>/Developer/SDKs/MacOSX*.sdk/</samp> 内の同名のヘッダファイルには、次のようなマクロ定義があります。</p>
|
||
<pre>
|
||
#define __DARWIN_NO_LONG_LONG (defined(__STRICT_ANSI__) \
|
||
&& (__STDC_VERSION__-0 < 199901L) \
|
||
&& !defined(__GNUG__))
|
||
</pre>
|
||
<p>そして、このマクロが <samp>stdlib.h</samp> 等で次のように使われています。</p>
|
||
<pre>
|
||
#if __DARWIN_NO_LONG_LONG
|
||
</pre>
|
||
<p>このマクロは次のように定義すべきです。*1</p>
|
||
<pre>
|
||
#if defined(__STRICT_ANSI__) \
|
||
&& (__STDC_VERSION__-0 < 199901L) \
|
||
&& !defined(__GNUG__)
|
||
#define __DARWIN_NO_LONG_LONG 1
|
||
#endif
|
||
</pre>
|
||
<p>注:</p>
|
||
<p>*1 その理由は <a href="#3.9.4.6">3.9.4.6</a>, <a href="#3.9.8.6">3.9.8.6</a> を参照。</p>
|
||
|
||
<h4>3.9.10.3. #endif 行のトークン</h4>
|
||
<p><samp>/System/Library/Frameworks/Kerberos.framework/Headers</samp> の <samp>gssapi.h, krb5.h, profile.h</samp> には次のような奇怪な #endif 行があります。</p>
|
||
<pre>
|
||
#endif \* __KERBEROS5__ */
|
||
</pre>
|
||
<p>この <samp>\* __KERBEROS5__ */</samp> というのはコメントのようですが、なぜわざわざこんな書き方を発明するのか、理解に苦しみます。
|
||
他のシステムの GCC ではこれにはウォーニングが出ますが、Apple-GCC ではたとえ <samp>-pedantic</samp> 等のオプションを付けてもウォーニングは出ません。
|
||
Apple-GCC では次の書き方についてもウォーニングが出ません。
|
||
C90 以前の感覚をいまだにひきずっています。</p>
|
||
<pre>
|
||
#endif __KERBEROS5__
|
||
</pre>
|
||
|
||
<h4>3.9.10.4. マクロの諸問題</h4>
|
||
<p>次のような特殊なマクロの使い方は、glibc のソースや Linux のシステムヘッダなどでしばしば見られるものですが、いずれも firefox 3.0b3pre のソースをコンパイルした限りでは、そこから include される Mac OS X のシステムヘッダ中には見られません。</p>
|
||
<ul>
|
||
<li>GCC 仕様の可変引数マクロ<br>
|
||
C99 の仕様の可変引数マクロはシステムヘッダでは稀に使われていますが、GCC 仕様のものは見られません。
|
||
<li>マクロ呼び出しのカラ引数
|
||
<li>Function-like マクロの名前に置換される object-like マクロ
|
||
</ul>
|
||
|
||
<h4>3.9.10.5. Apple-GCC の独自仕様</h4>
|
||
<p>Apple-GCC には一般の GCC と異なる独自の仕様がいくつかあります。</p>
|
||
<ul>
|
||
<li><p>Intel-Mac と PowerPC-Mac の双方のバイナリを１つのマシンで生成するためのもの</p>
|
||
<p>Mac OS X には x86 用と ppc 用の双方のコンパイラがインストールされます（片方はネイティブコンパイラ、他方はクロスコンパイラ）。
|
||
<samp>-arch</samp> という独自のオプションがあり、<samp>-arch i386 -arch ppc</samp> というふうに複数の CPU を指定すると、gcc がその回数だけ呼び出されて、それぞれの CPU 用のバイナリが生成され、さらにそれらを１つにバンドルした universal binary というものが生成されます。
|
||
また、<samp>-mmacosx-version-min=</samp> というオプションもあり、これを <samp>-isysroot</samp> や <samp>--sysroot</samp> オプションと合わせて使うことで、バイナリの互換性の範囲を Mac OS X のある程度の旧バージョンにまで広げることができるようになっています。
|
||
これらの拡張仕様は Mac OS X 用のバイナリ・パッケージを作る場合などに便利です。</p>
|
||
<p>プリプロセスに関しては、CPU によって一部の事前定義マクロが違うことに注意が必要です。</p>
|
||
<li><p>"framework" ディレクトリ</p>
|
||
<p>Mac OS には NeXTstep 以来の framework ディレクトリというものがあります。
|
||
framework はヘッダファイル・ライブラリ・ドキュメント・その他の共有リソースを１つにまとめたものです。
|
||
ここにあるヘッダファイルを include するには次のようなディレクティブを使います。</p>
|
||
<pre>
|
||
#include <Kerberos/Kerberos.h>
|
||
</pre>
|
||
<p>これは次のディレクティブと同じ形をしています。</p>
|
||
<pre>
|
||
#include <sys/stat.h>
|
||
</pre>
|
||
<p>このディレクティブで include されるのはどれかの include directory（この場合は <samp>/usr/include</samp>）の中の <samp>sys/stat.h</samp> というファイルですが、<samp><Kerberos/Kerberos.h></samp> のほうはそうではありません。
|
||
<samp>Kerberos</samp> はディレクトリ名でさえもありません。
|
||
こちらは <samp>/System/Library/Frameworks</samp> という framework directory の中の <samp>Kerberos.framework/Headers/Kerberos.h</samp> というファイルなのです。
|
||
そして、<samp>Kerberos.framework/Headers</samp> は <samp>Kerberos.framework/Versions/Current/Headers</samp> への symbolic-link となっています。
|
||
これは最も単純な例で、framework header のありかはもっとずっと複雑なものも多くあります。</p>
|
||
<p>いったいだれがこんな複雑なシステムを考えたのでしょうか。
|
||
プリプロセッサは path-list をあれこれ組み立てながらシステムヘッダをサーチしなけらばならないので、かなりの負荷がかかります。
|
||
ヘッダによってはそこからさらに多くの他のヘッダを include するものもあります。</p>
|
||
<li><p>"header map" ファイル</p>
|
||
<p>Mac OS X の IDE である Xcode.app では "header map file" というものが使われます。
|
||
これは include されるヘッダファイルをあらかじめサーチして、その path-list を *.hmap という名前のファイルに記録しておき、プリプロセスではそれを include directory のように参照するというものです。
|
||
header map file を生成するのは Xcode.app のツールですが、それを include directory のように読むのは Apple-GCC の拡張仕様です。</p>
|
||
<p>framework directory 中のヘッダファイルのサーチは負荷が大きいので、それを軽減するために考えられたものでしょうか。
|
||
しかし、header map file は独自仕様のバイナリファイルであり、透明性を欠いています。
|
||
むしろ framework directory のほうを整理して単純明快にしてもらいたいものです。</p>
|
||
<li><p>#endif 行のトークン</p>
|
||
<p>前節で見たように、#endif 行に何があろうとどんなオプションが指定されようと、Apple-GCC はウォーニングさえ出しません。
|
||
時代錯誤の感覚です。</p>
|
||
<li><p>コメント中の非 ASCII 文字</p>
|
||
<p>これは GCC の問題ではありませんが、framework header ではコメント中に ISO-8859-* (?) の copyright mark (0xA9) 等の非 ASCII 文字がしばしば使われています。
|
||
これはコメント中とは言え、multibyte character を使う環境では迷惑です。
|
||
文字の encoding に関する意識を少しは持ってもらいたいものです。
|
||
この種の文字は Linux の /usr/include 等でも時に見られますが、Mac OS の framework header には特に多いようです。</p>
|
||
</ul>
|
||
|
||
<h3><a name="3.9.11" href="#toc.3.9.11">3.9.11. firefox 3.0b3pre ソースのプリプロセス</a></h3>
|
||
<p>firefox の developing version である 3.0b3pre (2008/01) すなわち 3.0-beta3-prerelease のソースを、Linux/x86 + GCC 4.1.2 および Max OS X + GCC 4.0.1 でプリプロセッサを <b>mcpp</b> V.2.7 に置き換えてコンパイルしてみました。
|
||
<b>mcpp</b> は -K オプションのテストを兼ねて、すべて -Kv オプションを付けて実行し、その出力を cc1 (cc1plus) に渡しています。
|
||
その結果、コンパイルが正常に終了し、firefox のバイナリが生成されるのを確かめることができました。*1</p>
|
||
<p>firefox のソースのプリプロセス上の portability は全体としてはかなり高いものです。
|
||
glibc のソースによく見られるような GCC-local な仕様への依存はあまり見られません。
|
||
Linux と Mac OS X の GCC、Windows の Visual C を公式なターゲットとしているだけのことはあります。</p>
|
||
<p>とは言え、プリプロセスの portability の問題は GCC と Visual C さえ通ればすむわけでもありません。
|
||
以下に具体的に検討してみます。
|
||
なお、GCC の問題については重複を避けるため、ここでは説明しません。
|
||
<a href="#3.9.4">3.9.4</a>, <a href="#3.9.8">3.9.8</a> 等を参照してください。
|
||
firefox と対比するため glibc をしばしば引き合いに出していますが、glibc についてのコメントもこれらのセクションにあります。*2</p>
|
||
<p>注:</p>
|
||
<p>*1 ソースは mozilla.org の CVS リポジトリから checkout したものである。
|
||
これをコンパイルした１つの動機は <b>mcpp</b> の -K オプションをテストするためであった。
|
||
このオプションは Taras Glek の提案によるものであるが、彼は mozilla project で C/C++ ソースの refactoring に取り組んでいるので、<b>mcpp</b> の作者も firefox のソースをこのオプションのテストに使ったのである。
|
||
-K (-Kv) オプションについては <a href="#2.4">2.4</a> を参照。</p>
|
||
<p>*2 firefox のコーディング・ガイドラインは次のところにある。
|
||
しかし、内容はかなり古いものである。<br>
|
||
<a href="http://www.mozilla.org/hacking/portable-cpp.html">portable-cpp</a></p>
|
||
|
||
<h4>3.9.11.1. GCC-local な仕様はほとんど使われない</h4>
|
||
<p>glibc のソースで時々使われている次のような GCC-local な仕様は、firefox のソースには見られません。
|
||
ただし、Linux 上でコンパイルする場合は、システムヘッダに GCC2 仕様の可変引数マクロなどが出てきますが、それは別です。</p>
|
||
|
||
<ul>
|
||
<li>GCC 仕様の可変引数マクロ<br>
|
||
それどころか C99 仕様の可変引数マクロさえもまだ使われていません。
|
||
</ul>
|
||
<p>次のものは glibc でも最近のバージョンでは使われなくなっているものですが、firefox でも使われていません。</p>
|
||
<ul>
|
||
<li>行をまたぐ文字列リテラル
|
||
<li>#warning
|
||
<li>-isystem, -I- オプション
|
||
</ul>
|
||
|
||
<h4>3.9.11.2. #include_next</h4>
|
||
<p>しかし、<samp>#include_next</samp> だけは１つのディレクトリに限ってたくさんあります。
|
||
これは configure によって生成される <samp>config/system_wrappers</samp> というディレクトリです。
|
||
この中に生成されるのはすべて同じ形をした約 900 本のヘッダファイルです。
|
||
例えば <samp>stdio.h</samp> は次のようになっています。</p>
|
||
<pre>
|
||
#pragma GCC system_header
|
||
#pragma GCC visibility push(default)
|
||
#include_next <stdio.h>
|
||
#pragma GCC visibility pop
|
||
</pre>
|
||
<p>これは GCC 4.* の <samp>#pragma GCC visibility *</samp> の機能を利用するためのものです。
|
||
一方で、<samp>config/gcc_hidden.h</samp> というファイルがあります。
|
||
これは次のようなもので、これが多くの translation unit で -include オプションによって冒頭に読み込まれます。</p>
|
||
<pre>
|
||
#pragma GCC visibility push(hidden)
|
||
</pre>
|
||
<p>system_wrappers ディレクトリは最優先の include ディレクトリでなければならないので、常に最初の -I オプションで指定しなければならないというのが注意すべき点ですが、この #include_next の使い方は簡明であり、特に問題はないと思われます。</p>
|
||
<p>ただ、<samp>nsprpub</samp> ディレクトリでは -include gcc_hidden.h の代わりに -fvisibility=hidden オプションが指定される場合がしばしばありますが、その場合は system_wrappers のヘッダファイルは使われません。
|
||
このディレクトリはまだ整理されていないようです。</p>
|
||
|
||
<h4>3.9.11.3. C99 を指定せずに C99 の仕様を使う</h4>
|
||
<p>目立つのは C99 を指定せずに C99 の仕様を使うものです。
|
||
GCC ではソースファイル名が *.c だとデフォルトでは gnu89 という仕様が使われますが、これは C90 にいくつかの C99 仕様と GCC 独自の仕様を加えた折衷的なものです。
|
||
firefox のソースには、これを利用して次のような C99 の仕様を暗黙のうちに使っているものがあります。</p>
|
||
<ul>
|
||
<li><p>マクロ呼び出しのカラ引数</p>
|
||
<p>Linux のシステムヘッダを別とすれば、firefox 自身のソースでのカラ引数はわずかですが、まず次の３本のファイルにあります。
|
||
カラ引数が実際に使われているのは <tt>NS_ENSURE_TRUE</tt> という１つのマクロだけです。</p>
|
||
<p><samp>layout/style/nsHTMLStyleSheet.cpp, layout/generic/nsObjectFrame.cpp, intl/uconv/src/nsGREResProperties.cpp</samp></p>
|
||
<p>また、<samp>gfx/cairo/cairo/src</samp> の次のファイルにもあります。
|
||
これも実際には <tt>slim_hidden_ulp2</tt> という１つのマクロだけです。</p>
|
||
<p><samp>cairoint.h, cairo-font-face.c, cairo-font-options.c, cairo-ft-font.c, cairo-ft-private.h, cairo-image-surface.c, cairo-matrix.c, cairo-matrix.c, cairo-pattern.c, cairo-scaled-font.c, cairo-surface.c, cairo-xlib-surface.c, cairo.c</samp></p>
|
||
<p>これらのカラ引数は Linux では使われますが、Mac OS X では使われません。
|
||
いずれにしても、特に紛らわしいものではありません。</p>
|
||
<li><p>C90 の規定を超える translation limits</p>
|
||
<p>identifier の長さ、#include のネスト、マクロ定義の数などが C90 の最低保証限度を超える場合がしばしばあります。<br>
|
||
31 バイトを超える長い identifier はことに <samp>gfx/cairo/cairo/src/</samp> に多く見られます。
|
||
#include のネストが 8 レベルを超えたり、マクロ定義が 1024 個を超える場合もありますが、Linux や Mac OS X ではシステムヘッダだけでこの現象がしばしば起こるのでやむをえないでしょう。</p>
|
||
<li><p>C のソースであるにもかかわらず <samp>//</samp> コメントを使っているもの</p>
|
||
<p>ときどき見られます。
|
||
これは上記の <a href="http://www.mozilla.org/hacking/portable-cpp.html">ガイドライン</a> が禁止しているものですが、いまはほとんど問題はないでしょう。</p>
|
||
</ul>
|
||
<p>これらの仕様は Visual C 2005, 2008 でも使えます。
|
||
GCC では -std=c99 というオプションがあるので、それを使いたいところです。
|
||
しかし、Visual C には規格のバージョンを指定するオプションはないので、暗黙のうちに使うしかありません。
|
||
したがって、暗黙のうちに C99 の仕様を使うことについては、主要な処理系の現状では firefox のソースを責めることはできません。*1</p>
|
||
<p>ところで、暗黙のうちに C99 仕様を使っていながら、可変引数マクロはなぜか使われていません。
|
||
Visual C でも 2005 で使えるようになったのですが、2003 までは使えなかったので、避けていたのでしょうか。</p>
|
||
<p>注:</p>
|
||
<p>*1 C++ では GCC は "gnu++98" という仕様がデフォルトである。
|
||
これは C++98 + GCC extensions とされているが、実際には C99 の仕様が混在している。
|
||
一方、Visual C は C では C90、C++ では C++98 に準拠とされているが、実際にはどちらも C99 仕様と独自の仕様が混在しており、Visual C 2005, 2008 ではことにそうである。
|
||
すなわち、GCC も Visual C も諸規格と独自仕様が混在しているのである。
|
||
とりわけ Visual C は規格のバージョンを指定できないのが困るところである。</p>
|
||
|
||
<h4>3.9.11.4. Function-like マクロの名前に置換される object-like マクロ</h4>
|
||
<p>Function-like マクロの名前に置換される object-like マクロの定義は他のプログラムにもよく見られるものです。
|
||
firefox のソースにもあまり多くはありませんが、次のところに見られます。</p>
|
||
<samp>content/base/src/nsTextFragment.h,
|
||
modules/libimg/png/mozpngconf.h,
|
||
modules/libjar/zipstub.h,
|
||
modules/libpr0n/src/imgLoader.h,
|
||
nsprpub/pr/include/obsolete/protypes.h,
|
||
nsprpub/pr/include/private/primpl.h,
|
||
nsprpub/pr/include/prtypes.h,
|
||
parser/expat/lib/xmlparse.c,
|
||
security/nss/lib/jar/jarver.c
|
||
security/nss/lib/util/secport.h,
|
||
xpcom/glue/nsISupportsImpl.h
|
||
</samp>
|
||
<p>また、firefox を make することで多くのヘッダファイルへのリンクが開発環境用のディレクトリに作られ、それらは firefox の開発環境をインストールすると /usr/include/firefox-VERSION/ に入っていきますが、その中には上記のファイルへのシンボリックリンクがいくつかあります。
|
||
configure によって生成される <samp>mozilla-config.h</samp> にもこの種のマクロ定義があります。</p>
|
||
<p>これらはやはり function-like マクロとして書いたほうが、ソースがわかりやすくなります。
|
||
実際、firefox のソースにもその書き方は多くあります。
|
||
人によって書き方が異なるのでしょうが、これについてはコーディング・ガイドラインを決めたほうが良さそうです。</p>
|
||
|
||
<h4>3.9.11.5. 'defined' に展開されるマクロ</h4>
|
||
<p>glibc で時に見られる置換リスト中に 'defined' というトークンの出てくるマクロが、firefox にも１つだけあります。</p>
|
||
<p><samp>modules/oji/src/nsJVMConfigManagerUnix.cpp</samp>
|
||
というファイルでは次のようなマクロを定義して、
|
||
<pre>
|
||
#define NS_COMPILER_GNUC3 defined(__GXX_ABI_VERSION) && \
|
||
(__GXX_ABI_VERSION >= 102) /* G++ V3 ABI */
|
||
</pre>
|
||
自分自身の中で次のように使っています。</p>
|
||
<pre>
|
||
#if (NS_COMPILER_GNUC3)
|
||
</pre>
|
||
<p>このマクロは廃止して、#if 行は次のように改めるべきです。</p>
|
||
<pre>
|
||
#if defined(__GXX_ABI_VERSION) && (__GXX_ABI_VERSION >= 102) /* G++ V3 ABI */
|
||
</pre>
|
||
<p>このファイルが GCC でしかコンパイルされないものだとは言え、処理系の誤仕様を利用するのは良いことではありません。*1</p>
|
||
<p>注:</p>
|
||
<p>*1 <b>mcpp</b> も V.2.7 からは GCC-specific-build では #if 行のマクロに出てくる 'defined' を GCC と同様に処理するようにした。
|
||
しかし、ウォーニングが出るので、ソースを修正したほうが良い。</p>
|
||
|
||
<h4>3.9.11.6. #endif のうしろの token sequences</h4>
|
||
<p><samp>jpeg</samp> ディレクトリの中の次のファイルには、何と #endif 行にコメントがコメントマークなしに書かれている行があります。
|
||
いずれも最近のアプデートで発生したものです。</p>
|
||
<pre>
|
||
jmorecfg.h, jconfig.h, jdapimin.c, jdcolor.c, jdmaster.c
|
||
</pre>
|
||
<p>この書き方は 1990 年代の中ごろまでは UNIX 系のソフトウェアに見られましたが、いまではほぼ消失しているものです。
|
||
かの glibc の世界でさえも使われていません。
|
||
さすがに GCC もこれにはウォーニングを出します。
|
||
しかし、これらのソースはそんなことにはおかまいなしのようです。
|
||
Apple-GCC はウォーニングを出しませんが、これは Mac OS 上でエディットされたものなのでしょうか。</p>
|
||
|
||
<h4>3.9.11.7. プリプロセスを要するアセンブラソース</h4>
|
||
<p>アセンブラソースは *.s (*.asm) という名前になっていて、中にはマクロが使われているものもありますが、プリプロセッサが呼び出されることは原則としてありません。</p>
|
||
<p>しかし、Mac OS X / ppc では１つだけ例外があり、<samp>xpcom/reflect/xptcall/src/md/unix/xptcinvoke_asm_ppc_rhapsody.s</samp> でプリプロセッサが呼び出されます。
|
||
このファイルにはたった１行の #if ブロックが１つあるからですが、今となっては必要ないと思われるブロックです。</p>
|
||
|
||
<h4>3.9.11.8. -include オプション</h4>
|
||
<p>firefox のコンパイルでは configure で mozilla-config.h というヘッダファイルが生成されますが、大半のソースのコンパイルでこのヘッダを -include オプションで指定しています。
|
||
config/gcc_hidden.h についても同様です。
|
||
なぜこれらをソースの冒頭で #include しないのでしょうか？</p>
|
||
|
||
<h4>3.9.11.9. マクロの再定義</h4>
|
||
<p>マクロが黙って再定義されることが稀にあります。</p>
|
||
<ul>
|
||
<li><p>firefox の make では多くの場合 -DZLIB_INTERNAL というオプションが付加されて gcc (c++) が呼び出されます。
|
||
すなわち、<tt>ZLIB_INTERNAL</tt> は 1 に定義されます。
|
||
ところがこのマクロは <samp>modules/zlib/src/</samp> の何本かのソースで</p>
|
||
<pre>
|
||
#define ZLIB_INTERNAL
|
||
</pre>
|
||
<p>と 0 個のトークンに定義されているのです。
|
||
そして、次のように使われています。</p>
|
||
<pre>
|
||
# ifdef ZLIB_INTERNAL
|
||
</pre>
|
||
<p>この場合は実害はありませんが、マクロ定義が違っているのは感心しません。
|
||
たぶん Makefile のオプションのほうが余計なのでしょう。</p>
|
||
<li><p><samp>xpcom/build/nsXPCOMPrivate.h</samp> では <tt>MAXPATHLEN</tt> というマクロの定義が <samp>/usr/include/sys/param.h</samp> と異なるという問題があります。
|
||
これは関連するヘッダファイルによって <samp>/usr/include/sys/param.h</samp> を include したりしなかったり一定していないためです。
|
||
ヘッダファイルの整理が必要です。</p>
|
||
<li><p>Mac OS X では <samp>netwerk/dns/src/nsIDNKitInterface.h</samp> で <samp>/usr/include/assert.h</samp> で定義された <tt>assert</tt> マクロが再定義されます。
|
||
これは <samp>#undef assert</samp> を先に書くべきです。</p>
|
||
<li><p>Mac OS X では <samp>modules/libreg/src/VerReg.c</samp> で <tt>VR_FILE_SEP</tt> というマクロの奇妙な二重定義が起こります。</p>
|
||
<pre>
|
||
#if defined(XP_MAC) || defined(XP_MACOSX)
|
||
#define VR_FILE_SEP ':'
|
||
#endif
|
||
#ifdef XP_UNIX
|
||
#define VR_FILE_SEP '/'
|
||
#endif
|
||
</pre>
|
||
<p>Mac OS X では configure で <tt>XP_MACOSX</tt> と <tt>XP_UNIX</tt> の双方が定義されるからです。
|
||
意図的な二重定義のように見えますが、紛らわしいので、<tt>XP_UNIX</tt> が優先することがわかるように次のように書いたほうが良いでしょう。</p>
|
||
<pre>
|
||
#ifdef XP_UNIX
|
||
#define VR_FILE_SEP '/'
|
||
#elif defined(XP_MAC) || defined(XP_MACOSX)
|
||
#define VR_FILE_SEP ':'
|
||
#endif
|
||
</pre>
|
||
</ul>
|
||
|
||
<h4>3.9.11.10. 長大なコメント</h4>
|
||
<p>次のファイルには数百行以上におよぶ長大なコメントがあります。</p>
|
||
<p><samp>extensions/universalchardet/src/base/Big5Freq.tab, extensions/universalchardet/src/base/EUCKRFreq.tab,intl/unicharutil/src/ignorables_abjadpoints.x-ccmap, layout/generic/punct_marks.ccmap</samp></p>
|
||
<p>ことに <samp>intl/uconv/ucv*/</samp> というディレクトリには長大なコメントを持つファイルが多数あります。
|
||
中には１つのコメントが 8000 行を超えるものまであります！
|
||
それらはすべて *.uf, *.ut という名前になっています。
|
||
いずれも unicode とアジアの各種 encoding との間の mapping table のようで、ツールによって自動生成されるものです。
|
||
C/C++ のソースには見えませんが、C++ のソースから include されます。
|
||
コメントはある種のドキュメントか他のツールのための表のようです。</p>
|
||
<p>長大なドキュメントや表をコメントとしてソース中に含めるのは、いかがなものでしょうか。
|
||
ソースツリーに含めるとしても、ソースとは別のファイルに分離すべきでしょう。</p>
|
||
<p>以上のファイルはいずれも Linux では使われますが、Mac OS X では使われません。
|
||
他方で Mac OS X では framework ディレクトリ中のシステムヘッダがしばしば使われますが、その中にはコメントが大半を占めている奇妙なファイルが時々見られます。</p>
|
||
|
||
<h4>3.9.11.11. 改行コードの混在</a></h4>
|
||
<p>firefox のソースの改行コードは [LF] ですが、[CR][LF] の行が少し混ざっているファイルが数本あります。
|
||
これらはいずれも短いブロックで、ソースにパッチを挿入する時に、その部分だけ [CR][LF] になってしまったもののようです。
|
||
ソースを Windows 上で編集する時は、改行コード変換ツールでチェックすべきでしょう。</p>
|
||
<br>
|
||
|
||
<h2><a name="3.10" href="#toc.3.10">3.10. Visual C++ のシステムヘッダの問題</a></h2>
|
||
<p>Visual C++ 2003, 2005, 2008 でいくつかのサンプルプログラムのプリプロセスに <b>mcpp</b> を使ってみました。このシステムのシステムヘッダには、プリプロセス上の互換性が問題となるようなものはごく少ないようです。次のようなものはありますが、これらは他の処理系でもしばしば見られるもので、特に問題となるものではありません。</p>
|
||
<ol>
|
||
<li>C99 の仕様はほとんど実装されていなかったころから、C で // コメントが多用されてきた。<br>
|
||
<li>Function-like マクロの名前に展開される object-like マクロの定義が時々見られる。<br>
|
||
<li>Visual C++ 2003 では limits.h に間違ったマクロ定義が１つあった
|
||
（Visual C++ 2005 では直された。<a href="cpp-test.html#5.1.3.1"> cpp-test.html#5.1.3.1</a> の注2 を参照）。
|
||
<br>
|
||
</ol>
|
||
<p>Linux のシステムヘッダや glibc には GCC local な仕様がしばしば使われていますが、Visual C++ のシステムヘッダには Visual C++ local な書き方はあまり見られません。</p>
|
||
|
||
<h3><a name="3.10.1" href="#toc.3.10.1">3.10.1. コメントを生成するマクロ？</a></h3>
|
||
<p>しかし、Visual C++ には１つだけとんでもないマクロがあります。Visual C++ 2003 の <samp>Vc7/PlatformSDK/Include/wtypes.h</samp> には次のようなマクロ定義があります。*1</p>
|
||
<pre>
|
||
#define _VARIANT_BOOL /##/
|
||
</pre>
|
||
<p>そして、<samp>Vc7/PlatformSDK/Include/</samp> の <samp>oaidl.h, propidl.h</samp> で次のように使われています。</p>
|
||
<pre>
|
||
_VARIANT_BOOL bool;
|
||
</pre>
|
||
<p>これはいったい何でしょうか？<br>
|
||
これは <tt>_VARIANT_BOOL</tt> が // に展開されて、その結果、この行がコメントアウトされることを期待しているもののようです。そして、実際に Visual C の cl.exe ではそうなってしまいます！</p>
|
||
<p>しかし、// はトークン (preprocessing-token) ではありません。また、マクロの定義や展開は、ソースがトークンに分解されコメントが１個のスペースに変換されたあとのフェーズで処理されるものです。したがって、マクロによってコメントを生成することは決してできないのです。このマクロは // に展開されたところで、// は有効な preprocessing-token ではないので結果は undefined となるはずのものです。</p>
|
||
<p><b>mcpp</b> でこれらのヘッダファイルを使うためには、このマクロ定義をコメントアウトし、数ヵ所ある <tt>_VARIANT_BOOL</tt> 云々のところを次のように書き換えなければなりません。</p>
|
||
<pre>
|
||
#if !__STDC__ && (_MSC_VER <= 1000)
|
||
_VARIANT_BOOL bool;
|
||
#endif
|
||
</pre>
|
||
<p>Visual C 5.0 以降のバージョンしか使わないのであれば、この行は次のように本当にコメントアウトしてかまいません。</p>
|
||
<pre>
|
||
// _VARIANT_BOOL bool;
|
||
</pre>
|
||
<p>このマクロは論外ですが、それ以上に問題なのは、これをコメントとして処理してしまう Visual C / cl.exe のプリプロセスの実装です。この例には、このプリプロセッサの次のような深刻な問題が露呈しています。</p>
|
||
<ol>
|
||
<li>少なくともこの例では Token-base ではなく文字ベースのプリプロセスがされている。<br>
|
||
<li>マクロの展開結果がコメントとして扱われており、translation phases が混乱している。<br>
|
||
</ol>
|
||
<p>おそらく、cl.exe のプリプロセッサは非常に古い、どちらかと言えば文字ベースのプリプロセッサのソースを元にしているのでしょう。それに部分的に手を加えながらバージョンアップを繰り返してきていることが推測されます。</p>
|
||
<p>こうした非常に古いプログラム構造を持っていると推測されるプリプロセッサは多くあります。3.9 で見た GCC 2 / cpp もその１つです。こうしたプリプロセッサでは、部分的に手を加えれば加えるほどプログラム構造がゴチャゴチャしてくるので、いくら改良してもあるところで品質は頭打ちとなります。古いソースを捨てて、初めから書き直さない限り、すっきりしたプリプロセッサにはならないと思われます。</p>
|
||
<p>GCC 3 / cpp ではソースが新しく書き直されて、GCC 2 とは別のプリプロセッサとなりました。<b>mcpp</b> も、DECUS cpp という古いプリプロセッサのソースから出発しながら、出発してまもなく全面的に書き直されたものです。</p>
|
||
<p>注:</p>
|
||
<p>*1 Visual C++ 2005 express edition には Platform SDK は含まれていないが、"Platform SDK for Windows 2003" をダウンロードして使うことができる。その <samp>PlatformSDK/Include</samp> ディレクトリの <samp>wtypes.h, oaidl.h, propidl.h</samp> でも、このマクロは同じである。<br>
|
||
Visual C++ 2008 express edition の <samp>Microsoft SDKs/Windows/v6.0A/Include</samp> ディレクトリの同名のヘッダファイルでも同様である。</p>
|
||
|
||
<h3><a name="3.10.2" href="#toc.3.10.2">3.10.2. Identifier 中の '$'</a></h3>
|
||
<p>もう一つの問題は、Visual C++ 2008 のシステムヘッダではマクロ名に '$' を使うケースが突然増えたことです。
|
||
これは Visual C++ 2005 までにもなくはありませんでしたが、例外的なものにとどまっていました。
|
||
しかし、2008 ではあちこちに出てきています。</p>
|
||
<p>最も目立つのは <samp>Microsoft Visual Studio 9.0/VC/include/sal.h</samp> というヘッダです。
|
||
これは Visual C++ の SAL (standard source code annotation language) なるものをソース中に記述するためのマクロを定義しているものです。
|
||
ここでは '$' を含む名前が大量に使われています。
|
||
このヘッダは多くの標準ヘッダファイルから <samp>Microsoft Visual Studio 9.0/VC/include/crtdefs.h</samp> というヘッダを介して #include されます。
|
||
したがって、多くのソースのコンパイルではこれらのマクロが知らないうちに使われることになります。</p>
|
||
<p>-Za オプションを付けて cl（コンパイラ）を起動すると、SAL は無効になり、sal.h の '$' を含む名前はすべて消えるようにはなっていますが、なぜこんな名前が必要なのか理解に苦しみます。
|
||
GCC でも identifier に '$' が使えるのがデフォルトになっていますが、実際には使われている例はほとんど見掛けなくなっています。</p>
|
||
<p><samp>Microsoft SDKs/Windows/v6.0A/Include</samp> ディレクトリにもこの種の名前を持つヘッダファイルがあります。
|
||
<samp>specstrings*.h</samp> というヘッダです。
|
||
これらのヘッダは WinDef.h を介して Windows.h から include されますが、こちらは -Za オプションを指定しても '$' が消えるようには書かれておらず、単にエラーになるだけです。
|
||
したがって、Windows.h を include するソースは -Za オプションでコンパイルすることはできません。</p>
|
||
<br>
|
||
|
||
<h1><a name="4" href="#toc.4">4. 処理系定義の仕様</a></h1>
|
||
<p>Ｃ言語のプリプロセス仕様を逐一ここに書くわけにはゆきません。cpp-test.html に Standard C のプリプロセスについて詳しい解説を書いてあるので、そちらを読んでください。<b>mcpp</b> の各種モードの動作仕様については、<a href="#2.1"> 2.1</a> を見てください。ここでは Standard C で処理系定義とされているものを含めて、プリプロセスの周辺のいくつかの仕様を述べます。さらにこまかな処理系定義仕様については、5 診断メッセージに書いてあります。</p>
|
||
<br>
|
||
|
||
<h2><a name="4.1" href="#toc.4.1">4.1. 終了時の status 値</a></h2>
|
||
<p><b>mcpp</b> 終了時に親プロセスに返す値は internal.H というヘッダで定義されています。エラーがなかった場合は 0 を返し、エラーがあった場合は errno != 0 なら errno を errno == 0 なら 1 を返します。</p>
|
||
<br>
|
||
|
||
<h2><a name="4.2" href="#toc.4.2">4.2. Include directory のサーチパス</a></h2>
|
||
<p>#include directive で include するファイルは次の順序でサーチされます。</p>
|
||
<ol>
|
||
<li>#include ディレクティブの引数が "file-name" または <file-name> の形でない場合、それがマクロであればそれを展開する。その結果は "file-name", <file-name> のどちらかの形でなければならない。そうでない場合はエラーとなる。<br>
|
||
<br>
|
||
<li>"file-name" の形でも <file-name> の形でも file-name がフルパスリストであれば、そのままオープンする。オープンできなければエラーとする。<br>
|
||
<br>
|
||
<li>フルパスリストでなくて "file-name" の形であれば、次のディレクトリ（からの相対パス）と解釈してサーチする。-I1 オプションでは 3.1、-I2 では 3.2、-I3 ではその双方（この順で）となる。デフォルトでは、UNIX 系の処理系, GCC, Visual C 用では 3.2、その他では原則として 3.1 である。ただし、Borland C 版では 3.1+3.2である。
|
||
Compiler-independent 版では 3.2 である。<br>
|
||
<br>
|
||
3.1. カレントディレクトリ（もちろん <b>mcpp</b> 起動時の）。#include がネストされていても、常にカレントディレクトリを基準とする。<br>
|
||
3.2. ソースファイル（インクルード元）のあるディレクトリ。#include がネストされている場合、ヘッダファイルが別ディレクトリにあると、そのたびに基準がズレてゆく。<br><br>
|
||
GCC 版ではさらに -iqoute オプションで指定されたディレクトリがサーチされる。
|
||
Visual C 版ではソースファイルの親（インクルード元）ファイルのディレクトリも順次さかのぼって、サーチされる。
|
||
それで発見できなければ、<file-name> の形と同様のサーチをする。<br>
|
||
<br>
|
||
<li>フルパスリストでなくて <file-name> の形であれば、次のディレクトリをサーチする。これらのディレクトリそのものが相対パスで指定されている場合は、カレントディレクトリからの相対パスと解釈する。これらを順にすべてサーチしてもファイルをオープンできなければエラーとする。<br>
|
||
<br>
|
||
4.1. <b>mcpp</b> 起動時に -I <directory> オプションで指定されたディレクトリ。複数あれば指定された順に（左から）サーチする。<br>
|
||
4.2. GCC 版では -isystem オプションで指定されたディレクトリ。複数あれば指定された順に（左から）サーチする。<br>
|
||
4.3. 環境変数で指定されたディレクトリ。この環境変数の名前は、noconfig.H (configed.H) の <i>ENV_C_INCLUDE_DIR</i> で定義されている。C++ では <i>ENV_CPLUS_INCLUDE_DIR</i> が定義されていればその環境変数が先に使われる。GCC 版では C_INCLUDE_PATH（C++ では CPLUS_INCLUDE_PATH も）、その他では <samp>INCLUDE</samp>（C++ では <samp>CPLUS_INCLUDE</samp> も）をデフォルトの環境変数名としている。環境変数で複数のディレクトリが separator で区切って指定されていれば、それらを最初のものから順にサーチする（separator は Windows では ;、その他では :）。<br>
|
||
4.4. noconfig.H (configed.H) のマクロ <i>CPLUS_INCLUDE_DIR?</i> で定義された implementation-specific なディレクトリ。<br>
|
||
4.5. system.c の set_sys_dirs() で指定された site-specific なディレクトリ(UNIX 系では <samp>/usr/local/include</samp>)。<br>
|
||
4.6. noconfig.H (configed.H) のマクロ <i>C_INCLUDE_DIR?</i> で定義された implementation-specific なディレクトリ。<br>
|
||
4.7. system-specific なディレクトリ（UNIX 系では <samp>/usr/include</samp>）。<br>
|
||
</ol>
|
||
<p>-I- (GCC では -nostdinc、Visual C では -X) オプションを指定すると、上記の 4.4 以降のサーチは行われません。</p>
|
||
<p>パスの基準をカレントディレクトリとするのは、ANSI C Rationale では委員会の「意図 (intent)」であるとされています。基準ディレクトリが動くことがなく仕様が明確なので、妥当だと思われます。しかし、UNIX 系の処理系等では、少なくとも #include "header" の形式では include 元のソースファイルのあるディレクトリを基準とする習慣があるようです。<b>mcpp</b> も compiler-independent 版では大勢に従ってソースファイルのディレクトリを基準としました。</p>
|
||
<br>
|
||
|
||
<h2><a name="4.3" href="#toc.4.3">4.3. Header name の構築法</a></h2>
|
||
<p>Header-name という pp-token の構築法と、そこから実際の include file のファイル名を取り出す方法は、次の通りです。</p>
|
||
<ol>
|
||
<li>ソース中に文字列リテラルの形式で書かれていれば、それをそのまま header-name とする。ソース中にマクロで書かれていて、それを展開した結果が文字列リテラルになった場合も、同様である。文字列リテラルの形式の header-name では、単にその両端の " をとったものをファイル名とする。<br>
|
||
<li>ソース中に <filename> の形で書かれていれば、それをそのまま header-name とする。ソース中にマクロで書かれていて、それを展開した結果が <filename> の形になった場合も、同様である。マクロ中の space は複数の spaces を１個の space に圧縮した上で保存される。単に両端の <, > をとったものをファイル名とする。<br>
|
||
<li>どの場合でも、Windows では path-delimiter として \ も / も使えるが、\ は / に変換する。<br>
|
||
</ol>
|
||
<br>
|
||
|
||
<h2><a name="4.4" href="#toc.4.4">4.4. #if 式の評価</a></h2>
|
||
<p>#if 式の評価はホスト処理系（<b>mcpp</b> をコンパイルした処理系）とターゲット処理系（<b>mcpp</b> を使う処理系）が持つ最大の整数型によって決まります。双方の型が異なる時は、小さいほうの型が #if 式の型になります。Compiler-independent 版の <b>mcpp</b> ではターゲット処理系は存在しないので、ホスト処理系によって決まります。</p>
|
||
<p>pre-Standard モードでは #if 式は (signed) long だけで評価します。</p>
|
||
<p>long long を持たない処理系の Standard モードでは、long および unsigned long で行います。</p>
|
||
<p>long long を持つ処理系の Standard モードでは、#if 式は long long / unsigned long long で評価します。C90, C++98 では long / unsigned long で評価するのが規定ですが、<b>mcpp</b> では C90, C++98 でも long long / unsigned long long で評価し、long / unsigned long の範囲を超える場合はウォーニングを出します。*1</p>
|
||
<p>Visual C, Borland C 5.5 では long long はありませんが、それと同サイズの __int64 という型があるので、#if 式は __int64 / unsigned __int64 で評価します（ただし、Visual C++ 2002 までと Borland C 5.5 では LL, ULL という suffix が使えないので、これらの suffix は #if 行では使えるが地の文で使ってはいけない）。</p>
|
||
<p>また、-+ オプションで C++ のプリプロセスをする時は、#if 式中の true, false という pp-token の値はそれぞれ 1L, 0L と評価します。</p>
|
||
<p>Standard モードでの具体的な評価のしかたを、以下に説明します。long long を持たない処理系の場合は、以下の 4.4, 4.5 の記載はすべて、long long / unsigned long long をそれぞれ long / unsigned long と読み替えてください。Pre-Standard モードではすべて long と読み替えてください。</p>
|
||
<ol>
|
||
<li>個々の整数定数トークン（文字定数を含む）は、数値トークンに接尾子 U が付いていれば unsigned long long で評価する（pre-Standard モードでは接尾子 U は認知しない）。<br>
|
||
<li>そうでなければ、long long の非負の範囲におさまれば long long で評価する。<br>
|
||
<li>そうでなくて unsigned long long の範囲に入れば unsigned long long で評価する。<br>
|
||
<li>それも越える値は out of range のエラーとする。<br>
|
||
<li>二項演算は被演算数のどちらかが符号なしであれば符号なしで、そうでなければ符号つきで行う。<br>
|
||
</ol>
|
||
<p>どちらにしても整数定数トークンは常に非負の値をとります。<br>
|
||
pre-Standard モードでは整数定数トークンの評価は非負の long の範囲で行い、それを越える値は out of range とします。その演算もすべて long で行います。</p>
|
||
<p>また、ホストの unsigned long long のほうがターゲットよりも範囲が狭い場合は、それを超える値は out of range となります。<br>
|
||
定数同士の演算結果が範囲外となった場合は、long long では out of range のエラーとなり、unsigned long long ではウォーニングが出ます。演算の中間結果についても同様です。</p>
|
||
<p>負数の右ビットシフトや負数を含む割り算には移植性がないので、ウォーニングを出します。符号なし型と符号つき型の混合演算によって符号つき型の負の値が符号なし型の正の値に変換された場合も、ウォーニングを出します。実際の演算は、ホスト処理系のコンパイラ本体の仕様に従います。</p>
|
||
<p>C90, C++98 ではプリプロセスでの #if 式の評価はすべて long / unsigned long で（C99 ではその処理系の最大の整数型で）行うことになっています。<b>mcpp</b> では C90, C++98 でも long long / unsigned long long で評価し、long / unsigned long の範囲を超える場合はウォーニングを出します。どちらにしても、コンパイラ本体での if (expression) の評価の仕方よりは大ざっぱなものです。符号拡張が関係する場合には、コンパイラ本体とは違う結果になることが往々にしてあります。</p>
|
||
<p>また、Standard C のプリプロセスでは keyword というものが存在しないので、sizeof やキャストは使えません。もちろん、変数や列挙定数や浮動小数点数は使えません。Standard モードでは #if 式に defined 演算子が使え、#elif ディレクティブも使えます。あとはコンパイラ本体での if (expression) と同様に、各演算子の優先順位とグルーピング規則（いわゆる結合規則）に従って評価が行われます。２項演算子の多くでは、両辺を同型にするための算術変換が行われ、片方が unsigned long long の場合は他方は long long であっても unsigned long long に変換されます。</p>
|
||
<p>注:</p>
|
||
<p>*1 <b>mcpp</b> V.2.5 までは C90, C++98 では内部的には long long / unsigned long long で評価しながら、long / unsigned long の範囲を超える場合はエラーとしていたが、V.2.6 からは GCC や Visual C との互換性のためにエラーをウォーニングに格下げした。</p>
|
||
<br>
|
||
|
||
<h2><a name="4.5" href="#toc.4.5">4.5. #if 式での文字定数の評価</a></h2>
|
||
<p>#if 式の定数トークンとしては識別子（マクロ、非マクロ）、整数の数値トークン、文字定数がありますが、このうち文字定数の評価の仕方はほとんど implementation-defined であり、portability はあまりありません。#if 'const' と compiler-proper での if ('const') との間でさえも結果が違う場合があります（Standard C でも、これが同じであることは保証されていない）。</p>
|
||
<p><i>POSTSTD</i> モードではこのほとんど意味のない #if 式中の文字定数の評価は行いません（エラーとなる）。</p>
|
||
<p>文字定数の評価は他の整数定数トークンと同様に、long long, unsigned long long の範囲で常に正の値に評価します。pre-Standard モードでは long の範囲です。</p>
|
||
<p>Single character でない multi-byte character および wide character は、encoding が UTF-8 の場合は４バイト、それ以外ではすべて２バイトの型で評価します。UTF-8 はサイズが可変なので、４バイトの型で評価します。EUC-JP の３バイト encoding には対応していません（３バイト文字は１バイト＋２バイトの２文字として認識される。その結果、値は正しく評価されることになる）。２バイトの encoding でありながら、wchar_t が４バイトの型である処理系もありますが、<b>mcpp</b> は wchar_t には関知しません。以下では２バイトの multi-byte character encoding の場合について説明します。</p>
|
||
<p>'字' というような multi-byte character constant は ((１バイト目の値 << 8) + ２バイト目の値) と評価します（8 は <limits.h> の <tt>CHAR_BIT</tt> の値）。</p>
|
||
<p>'ab', '\x12\x3', '\x123\x45' というような multi-character character constant では、'a', 'b', '\x12', '\x3', '\x123', '\x45' 等をそれぞれ１バイトとして [0, 0xFF] の範囲で評価し、その結果を上位バイトから順次 8 ずつ左シフトさせながら足してゆきます（0xFF は <limits.h> の <tt>UCHAR_MAX</tt> の値）。１つの escape sequence の値が 0xFF を超えた時は、out of range のエラーとなります。したがって、文字セットが ASCII であれば、この３つのトークンの値はそれぞれ 0x6162, 0x1203, エラーとなります。</p>
|
||
<p>L'字' は '字' と同じ値となります。L'ab', L'\x12\x3', L'\x123\x45' 等の multi-character wide character constant については、L'a', L'b', L'\x12', L'\x3', L'\x123', L'\x45' をそれぞれ１つの wide character として [0, 0xFFFF] の範囲で評価し、その結果を上位の wide character から順次 16 ずつ左シフトさせながら足してゆきます。１つの escape sequence の値が２バイト符号なし整数の最大値を超えた時は、out of range エラーとなります。したがって、文字セットが ASCII であれば、この３つのトークンの値はそれぞれ 0x00610062, 0x00120003, 0x01230045 となります。</p>
|
||
<p>Multi-character character constant, multi-character wide character constant の値が unsigned long long の範囲を超えた時は out of range エラーとなります。</p>
|
||
<p><tt>__STDC_VERSION__</tt> または <tt>__cplusplus</tt> の値が 199901L 以上の場合は、\uxxxx, \Uxxxxxxxx の形の UCN (universal-character-name) を１６進 escape sequence として評価します（こういう評価をしても何の意味もないが、しかしこう評価するしかないのである）。</p>
|
||
<p>ターゲット処理系のコンパイラ本体で char や wchar_t が符号ありの場合は、#if 式での文字定数の評価とコンパイラ本体での if (expression) による文字定数の評価とは、結果が違ってくることがあります。範囲エラーとなる範囲も違う可能性があります。また、multi-character character constant, multi-byte character constant の評価は、プリプロセッサだけでなくコンパイラ本体でも処理系によってまちまちです。<tt>CHAR_BIT</tt> が８であっても、'ab' を 'a' * 256 + 'b' と評価するか、それとも 'a' + 'b' * 256 と評価するかさえも、Standard C では決められていません。</p>
|
||
<p>一般に、#if 式では文字定数はそれに代わる手段がある限りは使うべきではありません。それに代わる手段がない場合というのは、私には思い付きませんが。</p>
|
||
<br>
|
||
|
||
<h2><a name="4.6" href="#toc.4.6">4.6. #if sizeof (type)</a></h2>
|
||
<p>Standard C ではプリプロセスは実行時環境やコンパイラ本体の仕様から独立した文字通りのプリプロセスとして規定が明確にされ、その結果、#if 行では sizeof とキャストは使えないことになりました。しかし、pre-Standard モードでは #if 行で sizeof (type) が使えるようになっています。これは DECUS cpp を継承して、それに long long, long double の処理を追加する等の手を加えたものです（さすがにキャストを実装するのは煩雑なので、やっていない。やる気もない）。</p>
|
||
<p>eval.c の <i>S_CHAR</i> 等の S_* というマクロでは各型のサイズが定義されていますが、クロス処理系で使う場合は、もしホストとターゲットとでこれらの型の扱いが異なるなら、その値としてターゲット処理系のこれらの型のサイズを整数値で直接書く必要があります。</p>
|
||
<p><b>mcpp</b> の #if sizeof には手抜きがあります。char, short, int, long, long long の頭に付く signed, unsigned は単に無視します。また、sizeof (void *) はサポートしません。いささか中途半端ですが、こういう後ろ向きの機能のために system.H のフラグを増やして煩雑にしたくないのです。どうせキャストもサポートしないのだから sizeof は削除しようかとも思いましたが、せっかく旧版にあったものなので、若干の手を加えただけで残してあります。</p>
|
||
<br>
|
||
|
||
<h2><a name="4.7" href="#toc.4.7">4.7. White-space sequence の扱い</a></h2>
|
||
<p><b>mcpp</b> は translation phase 3 の tokenization に際して、token separator としての複数の white spaces の sequence は、改行コード以外は原則として one space に圧縮します。
|
||
しかし、<i>STD</i> モードで -k または -K オプションが指定されたときは、圧縮せずにそのまま出力します。
|
||
また、行末の white space sequence は削除します。
|
||
<p>行頭の white spaces は <i>POSTSTD</i> モードでは削除し、他のモードでは特別扱いで、そのまま出力します。
|
||
後者は人間が出力を読む場合のつごうに合わせてあります。*1</p>
|
||
<p>ただし、これはプリプロセスの中間段階の話です。その後に phase 4 があって、マクロ展開とプリプロセスディレクティブ行の処理が行われます。マクロ展開の後ではその前後に複数の spaces ができることがあります。もちろん、space がいくつあろうと、コンパイルの結果は何も変わりません。</p>
|
||
<p>Standard C では translation phase 3 でこれを one space に圧縮するかどうかは implementation-defined とされていますが、通常はユーザはまったく気にする必要はありません。Portability が問題になるのは、preprocessing directive 行に <vertical-tab> または <form-feed> がある場合だけです。この場合は Standard C では undefined です。<b>mcpp</b> ではこれらは space に変換します。</p>
|
||
<p>注:</p>
|
||
<p>*1 V.2.6.3 までは原則として one space に圧縮していたが、V.2.6.4 から変更した。</p>
|
||
<br>
|
||
|
||
<h2><a name="4.8" href="#toc.4.8">4.8. <b>mcpp</b> 実行プログラムのデフォルトの仕様</a></h2>
|
||
<p>noconfig ディレクトリにある各処理系用の差分ファイルと makefile を使ってデフォルトの設定でコンパイルした場合の <b>mcpp</b> 実行プログラムの仕様をここに書いておきます。Configure スクリプトで設定を生成してコンパイルした場合は configure の結果によって違ってきますが、OS と処理系のバージョンが同一であれば、少なくともインクルードディレクトリ以外は同じ結果になるはずです。</p>
|
||
<p>Compiler-independent 版の <b>mcpp</b> の仕様には処理系による相違はほとんどありませんが、OS と CPU による相違が少しあります。</p>
|
||
<p><b>mcpp</b> には compiler-independent-build と compiler-specific-build とがあり、そのどちらでもいくつかの動作モードがあります。それについては <a href=#2.1>2.1</a> を見てください。ここでは <i>STD</i> モードを中心に説明します。</p>
|
||
<p>これらの差分ファイルと makefile は次の処理系用のものです。</p>
|
||
<blockquote>
|
||
<table>
|
||
<tr><th>FreeBSD 6.3 </th><td>GCC V.3.4</td></tr>
|
||
<tr><th>Vine Linux 4.2 / x86 </th><td>GCC V.2.95, V.3.2, V.3.3, V.3.4, V.4.1</td></tr>
|
||
<tr><th>Debian GNU/Linux 4.0 / x86 </th><td>GCC V.4.1</td></tr>
|
||
<tr><th>Ubuntu Linux 8.04 / x86_64 </th><td>GCC V.4.2</td></tr>
|
||
<tr><th>Fedora Linux 9 / x86 </th><td>GCC V.4.3</td></tr>
|
||
<tr><th>Mac OS X Leopard / x86 </th><td>GCC V.4.0</td></tr>
|
||
<tr><th>CygWIN </th><td>1.3.10 (GCC V.2.95), 1.5.18 (GCC 3.4)</td></tr>
|
||
<tr><th>MinGW & MSYS </th><td>GCC 3.4</td></tr>
|
||
<tr><th>WIN32 </th><td>LCC-Win32 2003-08, 2006-03</td></tr>
|
||
<tr><th>WIN32 </th><td>Visual C++ 2003, 2005, 2008</td></tr>
|
||
<tr><th>WIN32 </th><td>Borland C++ V.5.5</td></tr>
|
||
</table>
|
||
</blockquote>
|
||
<p>このほか、私の持っていない次の処理系についても、ユーザから contribute された差分ファイルが収録されています。</p>
|
||
<blockquote>
|
||
<table>
|
||
<tr><th>WIN32 </th><td>Visual C++ V.6.0, 2002</td></tr>
|
||
<tr><th>WIN32 </th><td>Borland C++ V.5.9 (C++Builder 2007)</td></tr>
|
||
</table>
|
||
</blockquote>
|
||
<p>いずれもそれらの処理系自身でコンパイルされます。
|
||
</p>
|
||
<p>noconfig.H, system.H で定義されるマクロのうち、次のものはどの処理系用もすべて同じ設定にしてあります。</p>
|
||
<p><i>DIGRAPHS_INIT</i> == <i>FALSE</i> でコンパイルされているので、digraph は -2 (-digraphs) オプションで有効となります。<br>
|
||
<i>TRIGRAPHS_INIT</i> == <i>FALSE</i> としているので、trigraph は -3 (-trigraphs) オプションで有効となります。<br>
|
||
<i>OK_UCN</i> は <i>TRUE</i> にしているので、C99, C++ で UCN (universal character name) が使えます。<br>
|
||
<i>OK_MBIDENT</i> は <i>FALSE</i> としているので、識別子中に multi-byte-character は使えません。<br>
|
||
<i>STDC</i> は 1 としているので、<tt>__STDC__</tt> の初期値は 1 となります。</p>
|
||
<p>各種の translation limits は次のようにしています。</p>
|
||
<blockquote>
|
||
<table>
|
||
<tr><th><i>NMACPARS</i>（マクロの引数の最大数） </th><td>255</td></tr>
|
||
<tr><th><i>NEXP</i> （#if 式中の副式の最大ネストレベル） </th><td>256</td></tr>
|
||
<tr><th><i>BLK_NEST</i>（#if section の最大ネストレベル） </th><td>256</td></tr>
|
||
<tr><th><i>RESCAN_LIMIT</i>（マクロ再走査の最大ネストレベル）</th><td>64</td></tr>
|
||
<tr><th><i>IDMAX</i> （identifier の有効長） </th><td>1024</td></tr>
|
||
<tr><th><i>INCLUDE_NEST</i>（#include の最大ネストレベル） </th><td>256</td></tr>
|
||
<tr><th><i>NBUFF</i>（ソースの最大行長）*1 </th><td>65536</td></tr>
|
||
<tr><th><i>NWORK</i>（出力の最大行長） </th><td>65536</td></tr>
|
||
<tr><th><i>NMACWORK</i>（マクロ展開等の内部バッファのサイズ）</th><td>262144</td></tr>
|
||
</table>
|
||
</blockquote>
|
||
<p>ただし、GCC 版、Visual C 版では出力の最大行長は NWORK ではなく NMACWORK です。</p>
|
||
<p>次のマクロは OS によって異なった設定にしています。build type には関係しません。</p>
|
||
<p><i>MBCHAR</i> （デフォルトの multi-byte character encoding）</p>
|
||
<blockquote>
|
||
<table>
|
||
<tr><th>FreeBSD, Linux, Mac OS X </th><td>EUC_JP</td></tr>
|
||
<tr><th>Win32, CygWIN, MinGW </th><td>SJIS</td></tr>
|
||
</table>
|
||
</blockquote>
|
||
<p>次のマクロは処理系によって異なった設定にしています。
|
||
</p>
|
||
<p><i>STDC_VERSION</i> （<tt>__STDC_VERSION__</tt> の初期値）</p>
|
||
<blockquote>
|
||
<table>
|
||
<tr><th>Compiler-independent, GCC 2</th><td>199409L</td></tr>
|
||
<tr><th>その他 </th><td>0L</td></tr>
|
||
</table>
|
||
</blockquote>
|
||
<p><i>HAVE_DIGRAPHS</i> （digraphs をそのまま出力するか）</p>
|
||
<blockquote>
|
||
<table>
|
||
<tr><th>Compiler-independent, GCC, Visual C</th><td><i>TRUE</i></td></tr>
|
||
<tr><th>その他 </th><td><i>FALSE</i></td></tr>
|
||
</table>
|
||
</blockquote>
|
||
<p><i>EXPAND_PRAGMA</i> （C99 で #pragma 行の引数をマクロ展開するか）</p>
|
||
<blockquote>
|
||
<table>
|
||
<tr><th>Visual C, Borland C</th><td><i>TRUE</i></td></tr>
|
||
<tr><th>その他 </th><td><i>FALSE</i></td></tr>
|
||
</table>
|
||
</blockquote>
|
||
<p>GCC 2.7-2.95 では <tt>__STDC_VERSION__</tt> は 199409L となっていましたが、3.*, 4.* では <tt>__STDC_VERSION__</tt> はデフォルトでは事前定義されず、実行時オプションに応じて定義されるようになりました。<b>mcpp</b> の GCC 用の設定はこれに対応したものです。</p>
|
||
<p><i>STDC_VERSION</i> が 0L のものでは、<tt>__STDC_VERSION__</tt> はデフォルトでは 0L に pre-define されます。-V199409L オプションで <tt>__STDC__</tt> が 1 で <tt>__STDC_VERSION__</tt> が 199409L、事前定義マクロは '_' で始まるものだけという、厳密な C95 モードとなります。また、-V199901L オプションで C99 モードとなります。</p>
|
||
<p>C99 モードでは <tt>__STDC_HOSTED__</tt> が 1 に pre-define されます。<tt>__STDC_ISO_10646__</tt>, <tt>__STDC_IEC_559__</tt>, <tt>__STDC_IEC_559_COMPLEX__</tt> は <b>mcpp</b> 自身は pre-define しません。処理系のシステムヘッダに任せます。実際には、glibc 2 / x86 のシステムではシステムヘッダによって <tt>__STDC_IEC_559__</tt>, <tt>__STDC_IEC_559_COMPLEX__</tt> が 1 に定義され、他の処理系ではどれも定義されません。</p>
|
||
<p><i>HAVE_DIGRAPHS</i> が <i>FALSE</i> のものでは（digraph を実装していない処理系）、digraph は <b>mcpp</b> で通常の token に変換されてから出力されます。</p>
|
||
<p><i>EXPAND_PRAGMA</i> が <i>TRUE</i> であっても、STDC, MCPP, GCC のどれかで始まる #pragma 行はマクロ展開しません。</p>
|
||
<p>Include ディレクトリは次のように設定してあります。<br>
|
||
まず、UNIX 等で言ういわゆる system-specific なものおよび site-specific なものは次の通りです。これは compiler-independent 版でも同じです。</p>
|
||
<blockquote>
|
||
<table>
|
||
<tr><th>FreeBSD, Linux, Mac OS X, CygWIN</th><td>/usr/include, /usr/local/include</td></tr>
|
||
</table>
|
||
</blockquote>
|
||
<p>Mac OS X ではこのほか、framework ディレクトリが /System/Library/Frameworks, /Library/Frameworks に設定されます。</p>
|
||
<p>MinGW では /mingw/include が標準の include ディレクトリになります。</p>
|
||
<p>処理系やそのバージョンによって異なる implementation-specific なものについては *.dif ファイルを見てください。Compiler-independent 版ではこれらは定義されません。Windows の処理系ではこれらは特に設定せず、環境変数を参照します。環境変数は INCLUDE, CPLUS_INCLUDE です。Compiler-independent 版でも同様。<br>
|
||
これでつごうが悪ければ、設定を変えて <b>mcpp</b> をリコンパイルするか、環境変数で指定するか、-I オプションで指定するかしてください。</p>
|
||
<p><b>mcpp</b> は GCC 版, Visual C 版以外では、プリプロセスした結果が <i>NWORK</i>-1 を超える時は、これ以下の長さに行を分割して出力します。文字列リテラルの長さは <i>NWORK</i>-2 以下でなければなりません。</p>
|
||
<p>念のために繰り返しますが、以上の <i>italic</i> で表示されているマクロはいずれも <b>mcpp</b> をコンパイルした時のものであり、<b>mcpp</b> の実行プログラムが持っている組み込みマクロではありません。</p>
|
||
<p>入力ファイルを指定せずに <b>mcpp</b> を起動して、#pragma MCPP put_defines と打ち込むと、組み込みマクロの一覧が表示されます。</p>
|
||
<p><tt>__STDC__</tt> が 1 以上の状態では、_ で始まらない組み込みマクロは削除されます。-N (-undef) オプションでは <tt>__MCPP</tt> 以外がすべて削除されます。その上で -D オプションで設定し直してもかまいません。処理系のバージョンが少し違うだけで include directory が違わない場合は、<b>mcpp</b> をリコンパイルしなくても、この方法でバージョンマクロを再定義することで別バージョンに対応させることができます。-N や -U を使わなくても、-D で特定のマクロだけ再定義することができます。</p>
|
||
<p>-+ (-lang-c++) オプションで C++ のプリプロセスを指定した時は、<tt>__cplusplus</tt> が事前定義されますが、その初期値は 1L です。そのほかにさらにいくつかのマクロが事前定義されます。</p>
|
||
<p>GCC では V.3.2 までは事前定義マクロと言っても GCC が事前定義するものは少なく、多くは gcc から cpp に -D オプションで渡されるものでした。それとの互換性のためには <b>mcpp</b> で定義する必要はないのですが、<b>mcpp</b> を（"pre-preprocess" 等で）単体で動かす時の便宜のために <b>mcpp</b> 内で定義しています。<br>
|
||
GCC V.3.3 以降は突然、60 個から 70 個のマクロが事前定義されるようになりました。<b>mcpp</b> V.2.5 以降でも GCC 専用版ではやむなくこれを取り込んでいます。したがって、GCC V.3.3 以降用の <b>mcpp</b> では上記のほかに多くのマクロが事前定義されます。その内容は <b>mcpp</b> をインストールする時に生成される mcpp_g*.h というヘッダファイルでわかります。</p>
|
||
<p>FreeBSD, Linux, CygWIN, MinGW / GCC, LCC-Win32, Visual C 2008 は long long を持っているので、#if 式は long long, unsigned long long で評価します。Visual C 6.0, 2002, 2003, 2005, Borland C 5.5 では long long はありませんが、__int64, unsigned __int64 という型があるのでこれを使います。</p>
|
||
<p>これらの処理系では long の範囲はいずれも</p>
|
||
<pre>
|
||
[-2147483647-1, 2147483647] ([-0x7fffffff-1, 0x7fffffff])
|
||
</pre>
|
||
<p>です。unsigned long はいずれも</p>
|
||
<pre>
|
||
[0, 4294967295] ([0, 0xffffffff])
|
||
</pre>
|
||
<p>の範囲です。
|
||
</p>
|
||
<p>long long を持つ処理系ではいずれも long long の範囲は</p>
|
||
<pre>
|
||
[-9223372036854775807-1, 9223372036854775807]
|
||
([-0x7fffffffffffffff-1, 0x7fffffffffffffff])
|
||
</pre>
|
||
<p>で、unsigned long long の範囲は</p>
|
||
<pre>
|
||
[0, 18446744073709551615] ([0, 0xffffffffffffffff])
|
||
</pre>
|
||
<p>です。
|
||
</p>
|
||
<p>これらの処理系本体ではいずれも符号つき整数型の内部表現は２の補数であり、ビット演算もそれに対応しているので、<b>mcpp</b> の #if 式でも同様です。<br>
|
||
負の整数の右シフトはいずれも算術シフトであり、<b>mcpp</b> の #if 式でも同様です（１ビットの右シフトで値が符号つきのまま 1/2 になる）。<br>
|
||
整数の除算・剰余算で operand の片方または双方が負である場合はいずれも Standard C の ldiv() 関数と同じ代数的演算が行われるので、<b>mcpp</b> の #if 式でも同様です。</p>
|
||
<p>これらのシステム（ＯＳ）ではいずれも基本文字セットが ASCII なので、<b>mcpp</b> でも同様です。</p>
|
||
<p>私が書いた kmmalloc というメモリー管理ルーチンがあり、malloc(), free(), realloc() 等を含んでいますが、CygWIN, Visual C 2005, 2008 以外ではこれがインストールされている場合は、make する時に MALLOC=KMMALLOC（または -DKMMALLOC=1）というオプションを指定するとこれが link されます。ヒープメモリのデバッグ用ルーチンもリンクされるようになっています。errno の番号 <i>EFREEP</i>, <i>EFREEBLK</i>, <i>EALLOCBLK</i>, <i>EFREEWRT</i>, <i>ETRAILWRT</i> には Linux, LCC-Win32 ではそれぞれ 2120, 2121, 2122, 2123, 2124 を、それ以外ではそれぞれ 120, 121, 122, 123, 124 を割り当てています（<a href="mcpp-porting.html#4.extra"> mcpp-porting.html#4.extra</a> 参照）。*2</p>
|
||
<p>GNU のシステムおよび Visual C 以外では、環境変数 TZ はあらかじめ JST-9 にセットしておく必要があります。そうしないと、<tt>__DATE__</tt>, <tt>__TIME__</tt> マクロの値がズレてしまいます。</p>
|
||
<p>注:</p>
|
||
<p>*1 これは <backslash><newline> による行接続をした後の行長にも、コメントを a space に変換した後の行長にも適用される。コメントが複数行にまたがっている場合、コメントの変換によってそれが１行に連結されることに注意。</p>
|
||
<p>*2 CygWIN 1.3.10, 1.5.18 では malloc() に _malloc_r() 等といった内部ルーチンがあり、他のライブラリ関数にはそれらを呼び出すものがいくつかある。そのため、他の malloc() を使うことができない。Visual C 2005, 2008 でも、プログラム終了処理のルーチンが Visual C の malloc() の内部ルーチンを呼び出すので、やはり他の malloc() を使うことができない。</p>
|
||
<br>
|
||
|
||
<h1><a name="5" href="#toc.5">5. 診断メッセージ</a></h1>
|
||
|
||
<h2><a name="5.1" href="#toc.5.1">5.1. 診断メッセージの形式</a></h2>
|
||
<p><b>mcpp</b> が出す診断メッセージとその意味は、以下の通りです。診断メッセージはいずれも標準エラー出力に出力され、-Q オプションでカレントディレクトリ中の mcpp.err というファイルにリダイレクトされます。</p>
|
||
<p>診断メッセージは次の形をとっています。</p>
|
||
<ol>
|
||
<li>"filename:line: " に "fatal error: ", "error: ", "warning: " のどれかが続き、さらに 5.3 - 5.9 のメッセージのうちのどれかが続く。"filename:line: " に始まる１行の診断メッセージというのはいささか窮屈な仕様であるが、UNIX 上のＣ処理系での伝統的な診断形式で、各種のツールがこれを前提としているので採用している。画面上の１行におさまらないことがしばしばある。<br>
|
||
<li>マクロ展開中であれば、そのマクロ呼び出しが表示される。ネストされたマクロ呼び出しであれば、それぞれのマクロ名が表示される。そのマクロ定義も表示され、そのマクロ定義のあるソースファイル名と行番号も表示される。<br>
|
||
<li>ソースファイル名と行番号とその行が表示される。ファイルが include されたものであれば、include 元のファイルの名前と行番号と行が順次表示される。<br>
|
||
</ol>
|
||
<p>表示される行は通常は、ソースの「物理行」が行末の \ によって接続されたあとの「論理行」からさらにコメントを a space に変換した後のものであり、コメントが行をまたいでいる場合は複数の論理行が連結されたものとなる。行番号は連結された最後の物理行の番号である。ただし、コメント処理等の前の translation phase でのエラー等では、その phase の行が表示される。</p>
|
||
<p>ただし、-j オプションを指定した時は、上記の２と３は出力しません。</p>
|
||
<p>診断メッセージには次の３つのレベルがあります。</p>
|
||
<blockquote>
|
||
<table>
|
||
<tr><th>fatal error</th><td>プリプロセスをこれ以上続けても意味がない場合</td></tr>
|
||
<tr><th>error </th><td>構文や使用法が間違っている場合</td></tr>
|
||
<tr><th>warning </th><td>Portability のない場合や間違いの可能性のある場合</td></tr>
|
||
</table>
|
||
</blockquote>
|
||
<p>Warning
|
||
にはさらに次の５つのクラスがあります。Class 1, 2 以外はやや特殊なものです。</p>
|
||
<blockquote>
|
||
<table>
|
||
<tr><th>class 1 </th><td>間違いの可能性のある、または portability を欠いたソース</td></tr>
|
||
<tr><th>class 2 </th><td>規格上は問題があるが実際にはたぶん問題のないソース</td></tr>
|
||
<tr><th>class 4 </th><td>実際にはたぶん問題がない portability に関する warning</td></tr>
|
||
<tr><th>class 8 </th><td>スキップされる #if group や、#if 式中の評価をスキップされる副式等についてのお節介な warning</td></tr>
|
||
<tr><th>class 16</th><td>trigraph, digraph についての warning</td></tr>
|
||
</table>
|
||
</blockquote>
|
||
<p><b>mcpp</b> はきわめて多種の診断メッセージを用意しています。<i>STD</i> モードでは次のような種類にのぼっています。</p>
|
||
<blockquote>
|
||
<table>
|
||
<tr><th>fatal error </th><td>17 種</td></tr>
|
||
<tr><th>error </th><td>76 種</td></tr>
|
||
<tr><th>warning class 1 </th><td>49 種</td></tr>
|
||
<tr><th>warning class 2 </th><td>15 種</td></tr>
|
||
<tr><th>warning class 4 </th><td>17 種</td></tr>
|
||
<tr><th>warning class 8 </th><td>30 種</td></tr>
|
||
<tr><th>warning class 16</th><td> 2 種</td></tr>
|
||
</table>
|
||
</blockquote>
|
||
<p>これらについて、原則としてその行の中の問題の部分を具体的に指摘します。</p>
|
||
<p>なお、以下の説明では、診断メッセージで引用されるソース中のトークンや数値の部分には例として何かのトークンをはめこんでいます。そのうち、数値のかわりにマクロ名を書いているところは、実際にはそのマクロを展開した値が表示されます。<br>
|
||
また、場合によってエラーとして出たりウォーニングとして出たりするメッセージもあります。以下の説明では同一のメッセージについては最初に記載するところでだけ解説を加え、あとは単にメッセージを並べるだけにします。</p>
|
||
<br>
|
||
|
||
<h2><a name="5.2" href="#toc.5.2">5.2. Translation limits</a></h2>
|
||
<p>以下のエラーの中には、バッファのオーバーフロー等の <b>mcpp</b> の仕様上の制限によるものがあります。バッファサイズ等の translation limits は system.H のマクロで定義されています。必要な場合はその定義を大きくして <b>mcpp</b> をリコンパイルしてください（しかし、メモリの少ないシステムでは、あまり仕様を大きくすると out of memory が発生しやすくなるので、ほどほどに）。</p>
|
||
<br>
|
||
|
||
<h2><a name="5.3" href="#toc.5.3">5.3. Fatal error</a></h2>
|
||
<p>I/O エラーやメモリ不足等、プリプロセスをそれ以上続けることができない場合、バッファオーバーフロー等、プリプロセスを続けても意味がない場合に、このエラーメッセージが出て、プリプロセスを中止します。親プロセスには「失敗」の状態値を返します。</p>
|
||
<br>
|
||
|
||
<h3><a name="5.3.1" href="#toc.5.3.1">5.3.1. <b>mcpp</b> 自身のバグ</a></h3>
|
||
<ul>
|
||
<li><samp>Bug:</samp><br>
|
||
このメッセージは数種ありますが、いずれも <b>mcpp</b> 自身のバグを意味します。これが出ることはないと思いますが、もし出たらぜひその状況をご連絡ください。<br>
|
||
</ul>
|
||
|
||
<h3><a name="5.3.2" href="#toc.5.3.2">5.3.2. 物理的エラー</a></h3>
|
||
<ul>
|
||
<li><samp>File read error</samp><br>
|
||
ソースファイル読み込みのエラーです。ディスクかファイルシステムが傷んでいるのでしょう。<br>
|
||
<li><samp>File write error</samp><br>
|
||
出力ファイルの書き出しエラーです。ディスクかファイルシステムが傷んでいるかいっぱいになっているのでしょう。<br>
|
||
<li><samp>Out of memory (required size is 0x1234 bytes)</samp><br>
|
||
メモリが足りなくなりました（<b>mcpp</b> がヒープから 0x1234 bytes を取得しようとしたが、できなかった）。メモリの少ないシステムで長大なマクロ定義があまりにも多くある場合に発生します。ソースファイルを分割して、1 translation unit のマクロ定義を減らしてください。<br>
|
||
</ul>
|
||
|
||
<h3><a name="5.3.3" href="#toc.5.3.3">5.3.3. Translation limits と内部バッファのエラー</a></h3>
|
||
<ul>
|
||
<li><samp>Too long header name "long-file-name"</samp><br>
|
||
Include すべきファイルのパスリスト（指定のディレクトリのパスリストと連結したもの）が <i>PATHMAX</i> のサイズを超えています。<br>
|
||
<li><samp>Too long source line</samp><br>
|
||
ソースの物理行の長さが <i>NBUFF</i>-2 を超えています。Ｃのソースではないのでしょう。<br>
|
||
<li><samp>Too long logical line</samp><br>
|
||
ソースの物理行を行末の \ によって接続した論理行の長さが <i>NBUFF</i>-2 を超えています。あまりにも長大なマクロを定義した時に発生することがあります。そのようなコードはマクロではなく関数として書くべきでしょう。<br>
|
||
<li><samp>Too long line spliced by comments</samp><br>
|
||
コメントを a space に変換したあとの行の長さが <i>NBUFF</i>-2 を超えています。行をまたぐコメントによって多くの行を連結した場合に発生します。コメントを分離してください。<br>
|
||
<li><samp>Too long token</samp><br>
|
||
プリプロセス後の行に <i>NWORK</i>-2 を超える長さのトークンが含まれています。<b>mcpp</b> はコンパイラ本体の受け取れる行長 <i>NWORK</i> に出力行を分割しようとしますが、極端に長いトークンがあると分割しても出力できないことがあります。<br>
|
||
</ul>
|
||
<p>次の４つのエラーはトークンがさほど長くなくても、マクロ展開中にそのトークンのところでバッファオーバーフローになった場合にも起こります。その場合はマクロ呼び出しを分割してください。</p>
|
||
<ul>
|
||
<li><samp>Too long quotation "long-string"</samp><br>
|
||
文字列リテラル、文字定数または header-name が長すぎます。文字列リテラルであれば分割してください。隣接する文字列リテラルは Standard C の処理系であればコンパイラ本体が連結してくれます。<br>
|
||
<li><samp>Too long pp-number token "1234567890toolong"</samp><br>
|
||
Preprocessing-number token が長すぎます。Standard モードの場合です。<br>
|
||
<li><samp>Too long number token "12345678901234......"</samp><br>
|
||
Number token が長すぎます。pre-Standard モードの場合です。<br>
|
||
<li><samp>Buffer overflow scanning token "token"</samp><br>
|
||
token をスキャンしているうちにバッファオーバーフローとなりました。文字列リテラル、文字定数、header-name、pp-number 以外のトークンでは、こちらのメッセージが出ます。<br>
|
||
<br>
|
||
<li><samp>More than <i>BLK_NEST</i> nesting of #if (#ifdef) sections</samp><br>
|
||
#if, #ifdef, #ifndef 等のネストが <i>BLK_NEST</i> を超えています（<i>BLK_NEST</i> 等のマクロ名の部分は実際にはその値が表示される。以下同様）。#if section を分割してください。<br>
|
||
<li><samp>More than <i>INCLUDE_NEST</i> nesting of #include</samp><br>
|
||
#include のネストが <i>INCLUDE_NEST</i> を超えています。#include が無限再帰になっているのでしょう。<br>
|
||
</ul>
|
||
|
||
<h3><a name="5.3.4" href="#toc.5.3.4">5.3.4. #pragma MCPP preprocessed に関するエラー</a></h3>
|
||
<ul>
|
||
<li><samp>This is not the preprocessed source</samp><br>
|
||
#pragma MCPP preprocessed がありますが、これは <b>mcpp</b> によってプリプロセスされたソースファイルではありません。<br>
|
||
<li><samp>This preprocessed file is corrupted</samp><br>
|
||
これは <b>mcpp</b> によってプリプロセスされたソースファイルのようですが、壊れていて使えません。<br>
|
||
<br>
|
||
</ul>
|
||
|
||
<h2><a name="5.4" href="#toc.5.4">5.4. Error</a></h2>
|
||
<p>文法的な間違いがある場合にこのエラーメッセージが出ます。<br>
|
||
Standard C では、violation of syntax rule or constraint があった場合は処理系は何らかの診断メッセージを出さなければならないことになっていますが、Standard モードではこの violation に対しては原則としてエラーメッセージが出ます。一部はウォーニングです。</p>
|
||
<p>また、Standard C で undefined とされているものの多くについても error メッセージまたは warning が出ます。Undefined でありながら error も warning も出ないのは、次のものだけです。</p>
|
||
<ol>
|
||
<li>文字列リテラルの形の header name 中の ' と /*。これは単なる文字として扱われる。実際にはこれは、ファイルをオープンしようとしてエラーになるはずである（<, > で囲まれた header name の中ではこれらは文字定数およびコメントの開始と解釈されるので、何らかのエラーとなる）。header name の中では \ も undefined であるが、これもチェックしない。実際にはやはりファイルのオープンでエラーになるであろう（Windows 版では \ は class 2 の warning を出した上で / に変換して処理する）。<br>
|
||
<li>#undef defined。defined という名前を #undef するのは undefined であるが、<b>mcpp</b> では defined という名前のマクロを定義することはできないようになっているので、それが取り消されることもない。<br>
|
||
<li>コメント中に illegal な multi-byte character sequence があった場合は undefined であるが、これは実害はないので診断しない（文字列リテラル、文字定数、header name 中の illegal multi-byte character sequence にはウォーニングが出る）。<br>
|
||
<li>_ で始まる identifier は処理系のために予約されており、ユーザプログラムで定義すると結果は undefined であるが、プリプロセッサではユーザプログラムかそうでないかを必ずしも判別できないので、診断しない。<br>
|
||
<li>C99 でオプションとして規定されている事前定義マクロのうち、<tt>__STDC_ISO_10646__</tt>, <tt>__STDC_IEC_559__</tt>, <tt>__STDC_IEC_559_COMPLEX__</tt> は #define したり #undef したりすると undefined であるが、診断しない。これらのマクロは処理系のヘッダファイルで定義されることになるであろうが、プリプロセッサはユーザプログラムかどうかを必ずしも判別できないからである。<br>
|
||
<li>C99 の UCN については、translation phase 2 で <backslash><newline> を削除した結果 UCN に相当する sequence ができた場合、および文字列リテラルの連結によって UCN sequence が生成された場合は undefined であるが、これは診断しない（いずれも UCN として扱う）。<br>
|
||
</ol>
|
||
<p>Standard C のプリプロセスで具体的に何が violation of syntax rule or constraint で、何が undefined で何が unspecified で何が implementation-defined であるかについては、cpp-test.html を参照してください。</p>
|
||
<p>Fatal でない error メッセージが出てもプリプロセスは続けます。終了すると、エラーの数を表示し、親プロセスに「失敗」の状態値を返します。</p>
|
||
|
||
<h3><a name="5.4.1" href="#toc.5.4.1">5.4.1. 文字とトークンに関するエラー</a></h3>
|
||
<ul>
|
||
<li><samp>Illegal control character 0x1b, skipped the character</samp><br>
|
||
文字列リテラル、文字定数、header name、コメント以外のところに white space 以外のコントロールコードがあります。その文字をスキップして処理を続けます。<br>
|
||
</ul>
|
||
<p>次はトークンのエラーです。初めの４つはいずれもその行をスキップして処理を続けます。初めの３つは文字列リテラル等のトークンで、論理行の行末までに引用符が閉じられていないことを示します。</p>
|
||
<pre>
|
||
#error I can't understand.
|
||
</pre>
|
||
<p>などと、preprocessing-token sequence の形を成さないテキストを文字列リテラルでもコメントでもないところに書くと、この種のエラーとなります。Pre-processing-token は本来の（コンパイラ本体での）Ｃの token よりおおまかなもので、文字が source character set に含まれてさえいればほとんどの character sequence が何らかの pp-token sequence として通るので、preprocessing-token エラーとなるのはこれだけです。</p>
|
||
<p>なお、スキップされる #if group の中でも pp-token エラーはエラーとなります。</p>
|
||
<ul>
|
||
<li><samp>Unterminated string literal</samp><br>
|
||
文字列リテラルが完結していません。文字列リテラルは論理行をまたぐことはできません。必要なら、複数行に文字列リテラルを書いて、処理系にそれを連結させてください。このエラーは # 演算子による文字列化で発生することもありますが、その場合は行はスキップしません。<br>
|
||
<i>OLDPREP</i> モードではこれはエラーになりません（行末がリテラルの終わりとみなす）。<br>
|
||
また、-a (-lang-asm, -x assembler-with-cpp) オプションで起動された場合は、行をまたぐ文字列リテラルと判断して、\n を挿入して次の行と連結するので、エラーにはなりません（ウォーニングは出る）。<br>
|
||
<li><samp>Unterminated character constant 't understand.</samp><br>
|
||
文字定数が完結していません。<i>OLDPREP</i> モードおよび lang-asm モードではこれはエラーになりません（行末がリテラルの終わりとみなす）。<br>
|
||
<li><samp>Unterminated header name <header.h</samp><br>
|
||
header-name が完結してしません。<, > で囲まれる header-name 中に " または ' があった場合はこのエラーではなく上記２つのエラーとなります。また、<, > で囲まれる header-name 中に /* があった場合はそこから後がコメントと解釈されます。<br>
|
||
<li><samp>Empty character constant ''</samp><br>
|
||
文字定数の中身がカラです。
|
||
-a オプションが指定されたときは、これはエラーにはならずウォーニングが出ます。<br>
|
||
<li><samp>Illegal UCN sequence</samp><br>
|
||
std モードで <tt>__STDC_VERSION__</tt> の値が 199901L 以上の場合、または C++ の場合は、UCN が認識されますが、識別子中の \u, \U で始まる１６進 sequence のケタ数が、それぞれ４ケタ、８ケタに満ちていません。（#if 式中の文字定数でこれが起こったときは、Undefined escape sequence のウォーニングとなる。それ以外の場合は診断されない）。<br>
|
||
<li><samp>UCN cannot specify the value "0000007f"</samp><br>
|
||
UCN は１６進で [0, 9f], [d800, dfff] の範囲の値を指定することはできません。ただし、前者のうち 0x24 ($), 0x40 (@), 0x60 (`) は可です。前者はこの３文字を除くとすべて basic source character set の値と一致するので、使えません。また、後者は special characters のための reserved area となっています。ただし、C++ では後者の制限はありません（なぜか規格が微妙に違っている）。しかし、C++ でも -V199901L としてマクロ <tt>__cplusplus</tt> を 199901L 以上に事前定義した場合は、これに関しては C99 と同じ仕様になります。<br>
|
||
<li><samp>Illegal multi-byte character sequence "XY"</samp><br>
|
||
<i>OK_MBIDENT</i> == <i>TRUE</i> でコンパイルした Standard モードの場合、C99 では identifier 中に multi-byte character が使えますが、multi-byte character として認められない character sequence があるとエラーになります（identifier 以外の pp-token ではウォーニング）。<br>
|
||
</ul>
|
||
|
||
<h3><a name="5.4.2" href="#toc.5.4.2">5.4.2. 完結しないソースファイルのエラー</a></h3>
|
||
<p>次のメッセージはソースファイルが完結しない #if section、マクロ呼び出し等で終わっている場合に出ます。そのファイルで入力が終わりの場合（include されたファイルでない場合）は、"End of file" ではなく "End of input" と表示されます。<br>
|
||
これらの診断メッセージは <b>mcpp</b> のモードによって、エラーとなる場合とウォーニングとなる場合とあります。<br>
|
||
Standard モードではこれらはすべてエラーです。そのマクロ呼び出しはスキップし、#if section の対応関係はそのファイルが include された時の初期状態に戻します。<br>
|
||
pre-Standard モードではすべてウォーニングです。pre-Standard モードでも、<i>OLDPREP</i> モードでは unterminated macro call 以外はウォーニングさえも出ません。</p>
|
||
<ul>
|
||
<li><samp>End of file within #if (#ifdef) section started at line 123</samp><br>
|
||
123 行の #if (#ifdef, #ifndef) に対応する #endif がありません。<br>
|
||
<li><samp>End of file within macro call started at line 123</samp><br>
|
||
123 行で始まったマクロ呼び出しがファイルの終わりまでに完結していません。引数のカッコが対応していない場合やトークンエラーがあった時に、残りの部分を引数として読んでいってファイルの最後まで達することがあります（その前に Buffer overflow となるかもしれない）。また、マクロ展開の仕様がモードによって異なるので、あるモードでは意図通りに展開されるマクロが他のモードではこのエラーになることがあります。<br>
|
||
</ul>
|
||
|
||
<h3><a name="5.4.3" href="#toc.5.4.3">5.4.3. Preprocessing group 等の対応関係のエラー</a></h3>
|
||
<p>次は #if, #else 等の group の対応関係のエラーです。これらの行は無視して（それまでの group が続いているものとして）処理を続けます。これらのチェックはたとえスキップされる #if group の中にあっても行われます。<br>
|
||
なお、#if (#ifdef) section とは #if, #ifdef, #ifndef から #endif まで、#if (#elif, #else) group とは１つの #if (#ifdef) section のうちの #if (#ifdef, #ifndef), #elif, #else, #endif 等ではさまれた１つの行ブロックを指します。</p>
|
||
<ul>
|
||
<li><samp>Already seen #else at line 123</samp><br>
|
||
123 行に #else が現れた後にまた #else (#elif) が現れています。#endif を書き忘れたのかもしれません。<br>
|
||
<li><samp>Not in a #if (#ifdef) section</samp><br>
|
||
#if (#ifdef, #ifndef) なしに #else (#elif, #endif) が現れています。<br>
|
||
<li><samp>Not in a #if (#ifdef) section in a source file</samp><br>
|
||
Include されたソースファイルの中で、#if (#ifdef, #ifndef) なしに #else (#elif, #endif) が現れています。Include されたファイルが元ファイルの中にあればエラーにならないが、単一のファイルの中ではバランスがとれていないという場合です。Standard モードの時だけです（pre-Standard モードではウォーニング）。<br>
|
||
</ul>
|
||
<p>次の２つは #asm, #endasm の対応関係のエラーです。もちろん、pre-Standard モードの特定の処理系の場合だけです。</p>
|
||
<ul>
|
||
<li><samp>In #asm block started at line 123</samp><br>
|
||
123 行から始まった #asm ブロックの中にまた #asm があります。#asm は入れ子にできません。たぶん、#endasm を書き忘れたのでしょう。<br>
|
||
<li><samp>Without #asm</samp><br>
|
||
#asm ブロックの中ではないところに #endasm があります。<br>
|
||
</ul>
|
||
|
||
<h3><a name="5.4.4" href="#toc.5.4.4">5.4.4. ディレクティブ行の単純な構文エラー</a></h3>
|
||
<p>これ以降（5.4.12 まで）のエラーはスキップされる #if group の中では起こりません（-W8 オプションで起動すると、Unknown directive についてはウォーニングを出す）。<br>
|
||
次は # で始まるディレクティブ行の単純な文法エラーです。これらの行は無視して処理を続けます（すなわち、#if を section の開始とみなさず、#line では行番号は変わらない等）。#include, #line 行の引数がマクロであれば、それを展開したうえでチェックが行われます（pre-Standard モードでは展開しない）。<br>
|
||
下記のメッセージそのものにはディレクティブ名が出てきませんが、これに続いて表示されるソース行でディレクティブがわかります（ディレクティブ行はコメントが space に変換されると、必ず１行になる）。</p>
|
||
<ul>
|
||
<li><samp>Illegal #directive "123"</samp><br>
|
||
# に続くトークンが名前ではありません。# に続くのはディレクティブ名でなければなりません（しかし、<i>OLDPREP</i> モードでは #123 は #line 123 と同じものとして扱う）。<br>
|
||
<li><samp>Unknown #directive "pseudo-directive"</samp><br>
|
||
pseudo-directive というディレクティブは実装されていません。-a (-lang-asm, -x assembler-with-cpp) オプションで起動された場合は、エラーにはならずウォーニングになります。<br>
|
||
<li><samp>No argument</samp><br>
|
||
#if, #elif, #ifdef, #ifndef, #assert, #line の引数がありません。<br>
|
||
<li><samp>No header name</samp><br>
|
||
#include 行の引数がありません。または引数がマクロですが、それを展開したところ引数にはトークンが何もなくなりました。<br>
|
||
<li><samp>Not a header name "UNDEFINED_MACRO"</samp><br>
|
||
引数が header name ではありません。header name を定義するはずのマクロが定義されていない場合などです。<, > または ", " で囲まれたものが header name です。<br>
|
||
<li><samp>Not an identifier "123"</samp><br>
|
||
#ifdef, #ifndef, #define, #undef には identifier の引数が必要ですが、123 は identifier ではありません。<br>
|
||
<li><samp>No identifier</samp><br>
|
||
#define, #undef の引数がありません。<br>
|
||
<li><samp>No line number</samp><br>
|
||
#line の引数がマクロですが、それを展開したところ 引数には何もトークンが残らなくなってしまいました。<br>
|
||
<li><samp>Not a line number "name"</samp><br>
|
||
#line の第一の引数が数値トークン（preprocessing number）ではありません。<br>
|
||
<li><samp>Line number "0x123" isn't a decimal digits sequence</samp><br>
|
||
#line の第一引数は十進整数トークンでなければなりません。Standard モードの場合です（pre-Standard モードはウォーニングは出すが、１６進、８進等の整数トークンも認める）。<br>
|
||
<li><samp>Line number "2147483648" is out of range of [1,2147483647]</samp><br>
|
||
#line の第一引数は [1,2147483647] の範囲になければなりません。0 もエラーです。Standard モードの場合です。<br>
|
||
<li><samp>Not a file name "name"</samp><br>
|
||
#line の第二引数がある場合は通常の文字列リテラルでなければなりません。Identifier やワイド文字列リテラル等ではいけません。<br>
|
||
</ul>
|
||
<p>次のエラーは Standard モードの場合だけで、これらのディレクティブは無視されます。<i>OLDPREP</i> モードではエラーもウォーニングも出ず、<i>KR</i> モードではウォーニングとなり、この "junk" がなかったものとしてプリプロセスを続けます。</p>
|
||
<ul>
|
||
<li><samp>Excessive token sequence "junk"</samp><br>
|
||
#else, #endif, #asm, #endasm の行に余計なテキスト junk があります。#ifdef, #ifndef, #include, #line, #undef の行の正しい引数の後ろに余計なテキスト junk があります。それらはコメントとして書いてください。<br>
|
||
</ul>
|
||
|
||
<h3><a name="5.4.5" href="#toc.5.4.5">5.4.5. #if 式の構文エラー等</a></h3>
|
||
<p>次は #if, #elif, #assert ディレクティブ中の式の構文に関するエラーです。</p>
|
||
<p>#if (#elif) でエラーが起こった時は、その #if (#elif) 行は偽と評価されたものとして（すなわちその group をスキップして）、プリプロセスを続けます。</p>
|
||
<p>スキップされる #if (#ifdef, #ifndef, #elif, #else) group については、それがＣの legal な preprocessing token で成り立っているかどうかと、#if 等の group の対応関係はチェックしますが、その他の文法エラーはエラーにはなりません。</p>
|
||
<p>#if 行そのものの中では、評価をスキップされる部分式があります。例えば #if a || b のような式で a が真である場合は、b の評価は行われません。しかし、次の１４種の文法エラーないし translation limit のエラーはたとえ評価をスキップされる部分式中にあってもチェックされます。</p>
|
||
<ul>
|
||
<li><samp>More than <i>NEXP</i>*2-1 constants stacked at "12"</samp><br>
|
||
#if 式の評価で、スタックに積まれている定数が 12 のところで <i>NEXP</i>*2-1 以上になりました。#if 式のネストが深すぎます。<br>
|
||
<li><samp>More than <i>NEXP</i>*3-1 operators and parens stacked at "+"</samp><br>
|
||
#if 式の評価で、スタックに積まれている演算子とカッコの合計が + のところで <i>NEXP</i>*3-1 以上になりました（カッコは一対を２つと数える）。#if 式のネストが深すぎます。<br>
|
||
<li><samp>Misplaced constant "12"</samp><br>
|
||
#if 式の定数のあるべきでない位置に定数 12 があります。#if ではキャストは使えませんが、(int)0x8000 などとキャストを使ったりすると、int がマクロとして定義されていない identifier とみなされ 0 と評価されるので、(0)0x8000 となり、このエラーが発生します。<br>
|
||
<li><samp>Operator ">" in incorrect context</samp><br>
|
||
#if 式の妙な位置に > という演算子があります。マクロ MACRO が０個のトークンに定義されている時に、#if MACRO > 0 などとすると、マクロ展開の結果 #if > 0 となるので、このエラーとなります（この場合はその直前に Macro "MACRO" is expanded to 0 token というウォーニングが出るので、それとわかる）。<br>
|
||
<li><samp>Unterminated expression</samp><br>
|
||
#if 式が完結していません。MACRO が０個のトークンに定義されている時の #if a || MACRO などの場合です。<br>
|
||
<li><samp>Excessive ")"</samp><br>
|
||
#if 式に ( に対応しない余計な ) があります。<br>
|
||
<li><samp>Missing ")"</samp><br>
|
||
#if 式で ( に対応する ) がありません。<br>
|
||
<li><samp>Misplaced ":", previous operator is "+"</samp><br>
|
||
? に対応しない : があります。
|
||
<br>
|
||
<li><samp>Bad defined syntax</samp><br>
|
||
#if defined の文法が間違っています。かっこの対応がとれていなかったり、
|
||
identifier が引数になっていなかったりの場合です。マクロ展開の結果、このエラーが起こった場合は、このメッセージに続いてその展開結果を表示します。<br>
|
||
<li><samp>Can't use a string literal "string"</samp><br>
|
||
#if 式の定数には文字列リテラルは使えません。<br>
|
||
<li><samp>Can't use a character constant 'a'</samp><br>
|
||
<i>POSTSTD</i> モードでは #if 式の定数に文字定数、ワイド文字定数は使えません。<br>
|
||
<li><samp>Can't use the operator "++"</samp><br>
|
||
#if 式に使えない演算子があります。=, ++ 等です。<br>
|
||
<li><samp>Not an integer "1.23"</samp><br>
|
||
#if 行の定数には整数（文字定数を含む）しか使えません。<br>
|
||
<li><samp>Can't use the character 0x24</samp><br>
|
||
#if 式に使えない文字（コード 0x24）があります。
|
||
identifier, operator, punctuator, string literal, character constant, preprocessing number のどの preprocessing token にも合致しない、その文字１字のトークンです（コントロールコードはその前にチェックされているので、それ以外の文字）。
|
||
$ を identifier 中に認める処理系でも、オプションによってはこれが使えなくなります。
|
||
もちろん、スキップされる group の中にあるものはチェックされません。<br>
|
||
</ul>
|
||
<p>次は #if sizeof に関するエラーです。もちろん、pre-Standard の場合だけです。</p>
|
||
<ul>
|
||
<li><samp>sizeof: Syntax error</samp><br>
|
||
#if sizeof の文法が間違っています。かっこがなかったり、かっこが多すぎたり、かっこの対応がとれていなかったり、引数がなかったりする場合です。<br>
|
||
<li><samp>sizeof: No type specified</samp><br>
|
||
#if sizeof (type) の type が指定されていません。sizeof (*) などです。sizeof ((*)()) は関数へのポインタのサイズを求める legal な構文です。<br>
|
||
</ul>
|
||
|
||
<h3><a name="5.4.6" href="#toc.5.4.6">5.4.6. #if 式の評価に関するエラー</a></h3>
|
||
<p>次のエラーは評価をスキップされる部分式にある場合は起こりません（-W8 オプションではこれらについてもウォーニングが出る）。</p>
|
||
<p>#if 式は C99 ではその処理系の持つ最大の整数型で、C90, C++98 では long / unsigned long で評価するのが規定ですが、<b>mcpp</b> では C90, C++98 でも long long / unsigned long long で評価します。ただし、C90, C++98 で long / unsigned long の範囲を超えた場合はウォーニングを出します。<br>
|
||
long long のない処理系では、この節の long long / unsigned long long は long / unsigned long と読み替えてください。pre-Standard ではすべて (signed) long と読み替えてください。<i>POSTSTD</i> では #if 式に文字定数は使えないので、別のエラーになります。</p>
|
||
<ul>
|
||
<li><samp>Constant "123456789012345678901" is out of range</samp><br>
|
||
整数定数の値が unsigned long long で表現できる範囲を超えています。<br>
|
||
<li><samp>Integer character constant 'abcdefghi' is out of range</samp><br>
|
||
文字定数 'abcdefghi' の値が unsigned long long で表現できる範囲を超えています。<br>
|
||
<li><samp>Wide character constant L'abcde' is out of range</samp><br>
|
||
ワイド文字定数 L'abcde' の値が unsigned long long で表現できる範囲を超えています。<i>STD</i> モードの時だけです。<br>
|
||
<li><samp>8 bits can't represent escape sequence '\x123'</samp><br>
|
||
文字定数中の１つの escape sequence の値が 8 bits で表現できる範囲（[0, 0xFF]）を超えています。<br>
|
||
<li><samp>16 bits can't represent escape sequence L'\x12345'</samp><br>
|
||
ワイド文字定数中の１つの escape sequence の値が 16 bits （UTF-8 の場合は 32 bits）で表現できる範囲を超えています。<i>STD</i> モードの時だけです。<br>
|
||
<li><samp>Division by zero</samp><br>
|
||
#if 式に 0 による割り算があります。割り算は / によるものと % によるものがあります。#if dividend / divisor .. で divisor がマクロとして定義されていない場合などに起こります。#if defined divisor && (dividend / divisor ..) と書くことで、このエラーを避けることができます。<br>
|
||
<li><samp>Result of "op" is out of range</samp><br>
|
||
演算子 op による演算の結果が long long の範囲外となりました。op は２項演算子 *, /, %, +, - のどれかです。整数の内部表現が２の補数の場合は、単項 '-' 演算子も -<tt>LLONG_MIN</tt> でオーバーフローとなります。Unsigned long long はオーバーフローすることがないのでエラーにはなりませんが、代数的な演算結果が範囲外となる場合はウォーニングが出ます。<br>
|
||
</ul>
|
||
<p>次は sizeof に関するエラーです。スキップされる部分式では出ません（-W8 オプションではウォーニングが出る）。pre-Standard の場合です。</p>
|
||
<ul>
|
||
<li><samp>sizeof: Unknown type "type"</samp><br>
|
||
#if sizeof (type) の type が変です。<br>
|
||
<li><samp>sizeof: Illegal type combination with "type"</samp><br>
|
||
#if sizeof (long float) 等と、型の組み合わせが変です。<br>
|
||
</ul>
|
||
|
||
<h3><a name="5.4.7" href="#toc.5.4.7">5.4.7. #define のエラー</a></h3>
|
||
<p>次は #define に関するエラーです。
|
||
マクロは定義されません。</p>
|
||
<p>#, ## 演算子に関するエラーは Standard モードのものです。<br>
|
||
<samp>__VA_ARGS__</samp> に関するエラーも Standard モードの場合です。
|
||
可変引数マクロは C99 の仕様ですが、GCC, Visual C++ 2005, 2008 との互換性のために C90 でも C++ でも有効としています（ただし、ウォーニングが出る）。</p>
|
||
<ul>
|
||
<li><samp>"defined" shouldn't be defined</samp><br>
|
||
defined という名前のマクロは定義できません。これは Standard モードでチェックされます。<br>
|
||
<li><samp>"__STDC__" shouldn't be redefined</samp><br>
|
||
マクロ <tt>__STDC__</tt> は #define できません。<tt>__STDC_VERSION__</tt>, <tt>__FILE__</tt>, <tt>__LINE__</tt>, <tt>__DATE__</tt>, <tt>__TIME__</tt> も（C99 モードでの <tt>__STDC_HOSTED__</tt> と-+ オプションでの <tt>__cplusplus</tt> も）同様です。これは Standard モードでチェックされます。<br>
|
||
<li><samp>"__VA_ARGS__" shouldn't be defined</samp><br>
|
||
C99 では可変引数マクロの定義の置換リスト中に <samp>__VA_ARGS__</samp> というパラメータが使われますが、この identifier はマクロとして定義することはできません。<br>
|
||
<li><samp>More than <i>NMACPARS</i> parameters</samp><br>
|
||
マクロ定義でパラメータの数が <i>NMACPARS</i> を超えています。<br>
|
||
<li><samp>Empty parameter</samp><br>
|
||
マクロ定義にカラのパラメータがあります。
|
||
<br>
|
||
<li><samp>Illegal parameter "123"</samp><br>
|
||
マクロ定義で identifier 以外のトークンがパラメータに使われています。
|
||
Standard モードでは、identifier であっても <samp>__VA_ARGS__</samp> はパラメータとして使えません。<br>
|
||
<li><samp>Duplicate parameter name "a"</samp><br>
|
||
マクロ定義で a というパラメータ名が重複しています。<br>
|
||
<li><samp>Missing "," or ")" in parameter list "(a,b"</samp><br>
|
||
マクロ定義でパラメータリストを閉じる ) がありません。またはパラメータの直後に ',' でも ')' でもない別のトークンがあります。<br>
|
||
<li><samp>No token before ##</samp><br>
|
||
マクロ定義の置換リスト中の ## 演算子の前にトークンがありません。<br>
|
||
<li><samp>No token after ##</samp><br>
|
||
マクロ定義の置換リスト中の ## 演算子の後にトークンがありません。<br>
|
||
<li><samp>## after ##</samp><br>
|
||
マクロ定義の置換リスト中に ## ## というトークンの並びがあります。この定義はエラーではないという解釈もあるかもしれませんが、## というトークンが他のトークンと連結されると必ず valid でないトークンとなるので、このマクロの展開時には必ずエラーになります。<b>mcpp</b> ではこれはマクロ定義時にエラーにします。<br>
|
||
<li><samp>Not a formal parameter "id"</samp><br>
|
||
関数様マクロの定義で # 演算子のオペランド id がパラメータ名ではありません。<br>
|
||
<li><samp>"..." isn't the last parameter</samp><br>
|
||
"<samp>...</samp>" というパラメータはマクロ定義の最後のパラメータでなければなりません。（pre-Standard モードでは <samp>...</samp> は Illegal parameter エラーになる）。<br>
|
||
<li><samp>"__VA_ARGS__" without corresponding "..."</samp><br>
|
||
置換リスト中の <samp>__VA_ARGS__</samp> という identifier は <samp>...</samp> というパラメータがある場合しか使えません。<br>
|
||
</ul>
|
||
<p>GCC-specific-build の <i>STD</i> モードでは GCC2 仕様の可変引数マクロが使えますが、そのマクロ定義で <samp>__VA_ARGS__</samp> が使われていると、次のエラーになります。
|
||
<samp>__VA_ARGS__</samp> を使うなら GCC3 仕様か C99 仕様で書かなければなりません。</p>
|
||
<ul>
|
||
<li><samp>__VA_ARGS__ cannot be used in GCC2-spec variadic macro</samp><br>
|
||
</ul>
|
||
|
||
<h3><a name="5.4.8" href="#toc.5.4.8">5.4.8. #undef のエラー</a></h3>
|
||
<p>次は #undef に関するエラーです。</p>
|
||
<ul>
|
||
<li><samp>"__STDC__" shouldn't be undefined</samp><br>
|
||
マクロ <tt>__STDC__</tt> は #undef できません。
|
||
<tt>__STDC_VERSION__</tt>, <tt>__FILE__</tt>, <tt>__LINE__</tt>, <tt>__DATE__</tt>, <tt>__TIME__</tt> も（C99 モードでの <tt>__STDC_HOSTED__</tt> と -+ オプションでの <tt>__cplusplus</tt> も）同様です。これは Standard モードの場合にチェックされます。<br>
|
||
</ul>
|
||
|
||
<h3><a name="5.4.9" href="#toc.5.4.9">5.4.9. マクロ展開のエラー</a></h3>
|
||
<p>次はマクロ展開に関するエラーです。それらのマクロ定義も表示され、そのマクロ定義のあるソースファイル名と行番号も表示されます。#, ## 演算子に関するエラーは Standard モードだけです。</p>
|
||
<ul>
|
||
<li><samp>Less than necessary N argument(s) in macro call "macro( a)"</samp><br>
|
||
マクロ呼び出しの引数が足りません。macro には引数は N 個必要です。足りない引数には 0 個のトークンを割り当てて、処理を続けます。パラメータが１個で引数がゼロの場合はカラ引数と引数の欠落との区別がつきませんが、これはエラーにしません。<i>OLDPREP</i> モードではこれはウォーニングです。<br>
|
||
<li><samp>More than necessary N argument(s) in macro call "macro( a, b, c)"</samp><br>
|
||
マクロ呼び出しの引数が多すぎます。macro の引数は N 個のはずです。余計な引数を捨てて、処理を続けます。<i>OLDPREP</i> モードではこれはウォーニングです。<br>
|
||
<li><samp>Not a valid preprocessing token "+12"</samp><br>
|
||
## 演算子によって２つの pp-token を連結したところ、"+12" という invalid なものになりました。これは後で切り離されるかもしれませんが、このまま処理を続けます。-lang-asm (-x assembler-with-cpp, -a) オプションでは、これはウォーニングです。<br>
|
||
<li><samp>Not a valid string literal "\\"str\""</samp><br>
|
||
# 演算子によってマクロ呼び出しの引数を文字列化したところ、有効な（単一の）文字列リテラルとはならず、"\\"str\"" という token sequence になりました。リテラルの外に \ のあることが原因です（リテラルの外に \ がある引数を文字列化すると、Unterminated string literal のエラーになることもあり、何のエラーにならないこともある）。このまま処理を続けますが、たぶんコンパイルフェーズで再度エラーになるでしょう。<i>POSTSTD</i> モードではこのエラーは発生しません（Unterminated string literal はありうる）。<br>
|
||
</ul>
|
||
<p>以下のエラーでは、そのマクロ呼び出しはスキップされます。</p>
|
||
<ul>
|
||
<li><samp>Buffer overflow expanding macro "macro" at "something"</samp><br>
|
||
マクロの展開中に something のところでバッファがオーバーフローしました。マクロを分割してください。<br>
|
||
<li><samp>Unterminated macro call "macro( a, (b, c)"</samp><br>
|
||
マクロ呼び出しが完結していません。このエラーが起こるのはたいていは、ディレクティブ行でのマクロ呼び出しがその行で完結していない場合です。また、Standard モードでは引数中のマクロは引数の置換に先立って展開されますが、その時にそのマクロ呼び出しはその引数の中で完結していなければなりません。<i>POSTSTD</i> モードではマクロの置換リスト中にあるマクロ呼び出しが置換リストの中で完結していない場合も、このエラーとなります。<br>
|
||
<li><samp>Rescanning macro "macro" more than <i>RESCAN_LIMIT</i> times at "something"</samp><br>
|
||
マクロのネストが深すぎて、展開中に "something" のところで再走査の回数が <i>RESCAN_LIMIT</i> を超えました。Standard モードの場合だけですが、まず起こりえません。<br>
|
||
<li><samp>Recursive macro definition of "macro" to "macro"</samp><br>
|
||
マクロの定義が再帰的です。これは pre-Standard モードの時だけ起こりうるエラーです。再走査の回数が <i>PRESTD_RESCAN_LIMIT</i> に達すると再帰的マクロ定義とみなします。<br>
|
||
</ul>
|
||
<p>次のエラーは <i>STD</i> モードで -K オプションを指定したときだけのものです。
|
||
ともに、マクロが極端に複雑なため、macro notification のためのバッファが足りなくなったことを意味しています。
|
||
実際にはまず起こり得ません。</p>
|
||
<ul>
|
||
<li><samp>Too many magics nested in macro argument</samp>
|
||
<li><samp>Too many nested macros in tracing MACRO</samp>
|
||
</ul>
|
||
|
||
<h3><a name="5.4.10" href="#toc.5.4.10">5.4.10. #error, #assert</a></h3>
|
||
<ul>
|
||
<li><samp>#error</samp><br>
|
||
#error ディレクティブが実行されました。その #error 行が表示されます（引数そのものにトークンエラー（unterminated string 等）があった場合は #error は実行されない）。#error は Standard モードの場合だけです。<br>
|
||
<li><samp>Preprocessing assertion failed:</samp><br>
|
||
#assert ディレクティブが実行されました。この言葉に続いて #assert 行の引数が出力されます。引数の式そのものにエラーがあった場合は、assertion が失敗したものとみなします。#assert は pre-Standard モードで COMPILER != GNUC の場合だけです。<br>
|
||
</ul>
|
||
|
||
<h3><a name="5.4.11" href="#toc.5.4.11">5.4.11. #include の失敗</a></h3>
|
||
<ul>
|
||
<li><samp>Can't open include file "file-name"</samp><br>
|
||
Include すべきファイルが存在しない場合にこのエラーが発生します。たぶんファイル名のスペルミスか include directory の指定の間違いでしょう。<br>
|
||
</ul>
|
||
|
||
<h3><a name="5.4.12" href="#toc.5.4.12">5.4.12. その他のエラー</a></h3>
|
||
<p>次の２つは Standard モードの C99 だけのものです。
|
||
C++ でも -V199901L オプションで起動した場合は同様です。</p>
|
||
<ul>
|
||
<li><samp>Operand of _Pragma() is not a string literal</samp><br>
|
||
_Pragma() operator の引数は１個の文字列リテラルまたはワイド文字列リテラルでなければなりません。<br>
|
||
<li><samp>_Pragma operator found in directive line</samp><br>
|
||
_Pragma() operator は #pragma ディレクティブの代わりになるものです。
|
||
ディレクティブ行の中で使うことはできません。
|
||
</ul>
|
||
<br>
|
||
|
||
<h2><a name="5.5" href="#toc.5.5">5.5. Warning (class 1)</a></h2>
|
||
<p>文法的には間違いではないが何かの書き間違いの可能性がある場合や portability の問題のある場合に、warning が出ます。Warning には 1, 2, 4, 8, 16 の５つの class があります。<b>mcpp</b> の起動時に -W <n> というオプションを指定することで、これらが有効になります。<n> は 1, 2, 4, 8, 16 のうちの任意のものの OR をとったものです。なお、以下の説明で -W4 等と言っているのは、-W<n> で <n> & 4 が真の場合のことで、1|4, 1|2|4, 2|4, 1|4|8, 4|8, 4|16 等を含みます。</p>
|
||
<p>Standard モードでは Standard C で undefined とされている動作を引き起こすソースの多くは error にしますが、一部については warning を出します。</p>
|
||
<p>同様に Standard モードでは Standard C で unspecified とされている仕様を使うソースに対しては、次の点以外は必ず warning を出します。</p>
|
||
<ol>
|
||
<li>#if 式中の sub-expression の評価順序については、warning は出さない。||, &&, ? : 以外の演算子に関しては operand の評価順序は unspecified であるが、#if 式は副作用を生じないので、この評価順序は結果には影響しないからである。<b>mcpp</b> では、整数定数トークンの評価は常に出現と同時に左から右に行い、それらの間の演算は常に演算子のグルーピングの規則に従って、その項の値が必要になった時に初めて行う。<br>
|
||
</ol>
|
||
<p>Standard モードでは、implementation-defined とされている動作の多くについても warning を出します。Implementation-defined でありながら warning の出ないのは、次の点だけです。</p>
|
||
<ol>
|
||
<li>#include directive で include するファイルを探す場所、および #include の引数から header-name という pp-token を構築する方法。これに毎度 warning を出していたのではうるさい。header-name はマクロでなければ、ソースのトークンが space の有無も含めてそのまま使われる。マクロであれば、それを展開した結果が space の有無も含めてそのまま使われる（<i>POSTSTD</i> モードでは、マクロ展開によって pp-token 間に space が挿入されるが、その上で < から > までを space を削除してくっつけたものを header-name と解釈する。どちらにしても <i>POSTSTD</i> では <, > による header-name は obsolescent feature である）。Warning は出さないが、その代わりに、#pragma MCPP debug path, #debug path でサーチパスを表示する。<br>
|
||
<li>#if 式での single byte 文字定数（'a' 等）の評価と、単一の multi- byte character のワイド文字定数（L'字' 等）の評価。これは基本文字セットが同一であっても、single byte のカタカナとか、符号の有無とか、漢字の en-coding とかによって portability はごく限られるのであるが、キリがない。UCN についても同様である。<br>
|
||
<li>#if 式で負数がからむビット演算は整数の内部表現によって結果の値が異なるが、大半のマシンは２の補数の表現をとっているので、それを前提とすれば portability の問題はほとんど存在しない。ただし、負数の右ビットシフトおよび operand の片方または双方が負数の除算は portability が乏しいので、warning を出す。<br>
|
||
<li>Token separator としての複数の white spaces の sequence。Standard C では translation phase 3 でこれを one space に圧縮するかどうかは implementation-defined とされているが、通常はユーザはまったく気にする必要はない。Portability が問題になるのは、preprocessing directive 行に <vertical-tab> または <form-feed> がある場合だけである。<b>mcpp</b> ではこれらは space に変換するが、その時は warning を出す。複数の space, tab の sequence は one space に黙って圧縮する。<br>
|
||
<li>処理系独自の組み込みマクロについては warning は出さない。<br>
|
||
<li>#pragma sub-directive についても原則として warning は出さない。<b>mcpp</b> 自身が処理する #pragma once, #pragma __setlocale, #pragma MCPP * で引数が間違っている場合は、warning を出す。また、GCC V.3 での #pragma GCC poison (dependency) のように、処理系付属のプリプロセッサは処理するが <b>mcpp</b> は処理しない #pragma についても warning を出す。<br>
|
||
<li>C99 では、UCN sequence が # 演算子によって文字列化される場合、\ を \\ というふうに重ねるかどうかは implementation-defined となっているが、これについては warning は出さない。<b>mcpp</b> では \ は重ねない。<br>
|
||
</ol>
|
||
<p>したがって、<b>mcpp</b> ではプリプロセスのレベルでの portability のチェックをほぼ完全に行うことができます。</p>
|
||
<p><i>POSTSTD</i> モードでは、<a href="#2.1"> 2.1</a> にある仕様の違いを除けば <i>STD</i> モードと同様です。
|
||
</p>
|
||
<p>ウォーニングがいくつ出ても、「成功」の状態値を返します。-W0 のオプションで起動すると、ウォーニングは出ません。</p>
|
||
|
||
<h3><a name="5.5.1" href="#toc.5.5.1">5.5.1. 文字、トークンおよびコメントに関するウォーニング</a></h3>
|
||
<ul>
|
||
<li><samp>Converted [CR+LF] to [LF]</samp><br>
|
||
改行コードを [CR+LF] から [LF] に変換しました。Windows 用のソースファイルを UNIX 系のシステムでコンパイルすると、このウォーニングが出て、改行コードが自動的に変換されます。このウォーニングは１回しか出ません。Compiler-independent-build ではクラス１で、compiler-specific-build ではクラス２です。<br>
|
||
<li><samp>Illegal control character 0x1b in quotation</samp><br>
|
||
文字列リテラル、文字定数、header name 中に white space でないコントロールコードがあります。これらはコンパイラ本体でエラーになるかもしれません。そうでなくても、感心しないソースです。コントロールコードは文字列リテラル、文字定数では escape sequence で書くべきです。<br>
|
||
<li><samp>Illegal multi-byte character sequence "XY" in quotation</samp><br>
|
||
文字列リテラル、文字定数、header name 中の XY の１バイト目は multi-byte character（漢字）の１バイト目ですが、２バイト目は multi-byte character の２バイト目ではありません（"XY" の表示は化けるはず）。これは multi-byte character とみなさず、１バイト目を single byte character として、２バイト目は次の文字として扱います。<br>
|
||
いわゆる外字も規定の範囲のコードであれば、ウォーニングは出ません。また、規定の範囲にも実際には文字のない穴がところどころにありますが、<b>mcpp</b> は通常はそこまではチェックしません。規定の範囲は次の通りです。<br>
|
||
<blockquote>
|
||
<table>
|
||
<tr><th>encoding </th><td>first byte </td><td>second byte</td></tr>
|
||
<tr><th>shift-JIS </th><td>0x81-0x9f, 0xe0-0xfc</td><td>0x40-0x7e, 0x80-0xfc</td></tr>
|
||
<tr><th>EUC-JP </th><td>0x8e, 0xa1-0xfe </td><td>0xa1-0xfe</td></tr>
|
||
<tr><th>KS C 5601 </th><td>0xa1-0xfe </td><td>0xa1-0xfe</td></tr>
|
||
<tr><th>GB 2312-80 </th><td>0xa1-0xfe </td><td>0xa1-0xfe</td></tr>
|
||
<tr><th>Big Five </th><td>0xa1-0xfe </td><td>0x40-0x7e, 0xa1-0xfe</td></tr>
|
||
<tr><th>ISO-2022-JP</th><td>0x21-0x7e </td><td>0x21-0x7e</td></tr>
|
||
</table>
|
||
</blockquote>
|
||
ISO-2022-JP には文字コードのほかに shift sequence というものがあります。Shift sequence を別にすると、UTF-8 以外はすべて multi-byte character は２バイトです。<br>
|
||
UTF-8 では multi-byte character は２バイトまたは３バイト、稀に４バイトであり、大半の漢字は３バイトで encode されます。
|
||
１バイト目は 0xc2-0xef、２バイト目以降は 0x80-0xbf の範囲にありますが、詳細は省略します。どちらにしても、各バイトはこの範囲になければなりません。
|
||
また、この範囲内にも illegal な sequence が存在しますが、<b>mcpp</b> はこれにウォーニングを出します。。<br>
|
||
なお、EUC-JP の 0x8f + 0xa1-0xfe + 0xa1-0xfe の３バイト encoding （JIS X 0212 のいわゆる補助漢字）は１文字としては認識できず、0x8f, 0xa1-0xfe + 0xa1-0xfe の２文字として認識されますが、その結果、ウォーニングも出ず、#if 式中のワイド文字定数の評価以外は、正しく動作します。EUC-JP では１バイト目が 0x8e の文字（JIS X 0201 のいわゆる半角カタカナ）は２バイト encoding であるので、multi-byte character として扱われます。<br>
|
||
このウォーニングはスキップされる #if group の中では出ません。<br>
|
||
<li><samp>"/*" in comment</samp><br>
|
||
コメント中に /* という sequence があります。意図して書いたのでなければ、コメントの閉じ忘れでしょう。コメントはネストできません。<br>
|
||
<li><samp>Too long identifier, truncated to "very_long_identifier"</samp><br>
|
||
Identifier の長さが <i>IDMAX</i> を超えているので、<i>IDMAX</i> に縮めました。<br>
|
||
<li><samp>Illegal digit in octal number "089"</samp><br>
|
||
８進の数値トークン中に 8 または 9 の文字があります。pre-Standard モードでだけ出ます。Standard モードでは通常の行の数値トークンについては正誤の判定はしません。#if 式にこのトークンがあれば、それは Not an integer エラーの一種となります。<br>
|
||
<li><samp>Unterminated string literal, catenated to the next line</samp><br>
|
||
論理行中で閉じていない文字列リテラルは通常はエラーですが、-lang-asm (-x assembler-with-cpp, -a) オプションで起動された場合は、これは行をまたぐ文字列リテラルと解釈して、'\n' を挿入して次の行と連結します。こういうソースの書き方をするメリットは何もないので、「隣接する文字列リテラルの連結」の機能を使って書いてください。<br>
|
||
<li><samp>Unterminated character constant 't understand.</samp><br>
|
||
文字定数が完結していません。
|
||
lang-asm モードではこれはエラーにはなりません。<br>
|
||
<li><samp>Empty character constant ''</samp><br>
|
||
文字定数の中身がカラです。
|
||
lang-asm モードではこれはウォーニングですが、他のモードではエラーになります。<br>
|
||
</ul>
|
||
|
||
<h3><a name="5.5.2" href="#toc.5.5.2">5.5.2. 完結しないソースファイルのウォーニング</a></h3>
|
||
<p>ソースファイルの最後の行が中途半端である場合に、次のウォーニングが出ます。old_prep モードではウォーニングも出ません。</p>
|
||
<ul>
|
||
<li><samp>End of file with no newline, supplemented newline</samp><br>
|
||
ファイルが改行コードのない行で終わっていてはなりません。改行コードを補います。<br>
|
||
<li><samp>End of file with \, deleted the \</samp><br>
|
||
ファイルが <backslash><newline> で終わっていてはなりません。<backslash> を削除します。<br>
|
||
<li><samp>End of file with unterminated comment, terminated the comment</samp><br>
|
||
コメントの閉じ忘れです。コメントを閉じます。<br>
|
||
</ul>
|
||
<p>次のウォーニングは pre-Standard モードでしか出ません（Standard モードではエラー）。入力の終わりでない場合は、これらのウォーニングを無視して処理を続けますが、その結果はさらに妙なエラーを引き起こすでしょう。<i>OLDPREP</i> モードでは unterminated macro call 以外はウォーニングさえも出ません。</p>
|
||
<ul>
|
||
<li><samp>End of file within #if (#ifdef) section started at line 123</samp><br>
|
||
<li><samp>End of file within macro call started at line 123</samp><br>
|
||
<li><samp>End of file with unterminated #asm block started at line 123</samp><br>
|
||
123 行の #asm に対応する #endasm がありません。<br>
|
||
</ul>
|
||
|
||
<h3><a name="5.5.3" href="#toc.5.5.3">5.5.3. ディレクティブ行に関する各種のウォーニング</a></h3>
|
||
<ul>
|
||
<li><samp>The macro is redefined</samp><br>
|
||
これに続いて以前の定義のあるファイル名と行番号が表示されます。
|
||
<br>
|
||
マクロが以前とは違った内容で再定義されました。
|
||
ソースが整理されていないに違いありません。同じ名前のマクロの定義が重複している場合は、次の条件を満たしていないと再定義となり、このウォーニングが出ます。<br>
|
||
<ol>
|
||
<li>パラメータの数が同じ。<br>
|
||
<li>置換リストが同じ（ただし、トークン間の１個以上の white spaces はいくつあっても１つとみなす。<i>POSTSTD</i> では token separator があってもなくても自動的に a space に変換するので、token separator の違いは問題にならない）。<br>
|
||
<li><i>STD</i> モードではパラメータ名も同じ。<i>POSTSTD</i> ではこれはチェックしない。pre-Standard モードでもチェックしない。<br>
|
||
</ol>
|
||
<br>
|
||
<li><samp>Unknown argument "name"</samp><br>
|
||
#pragma MCPP debug, #debug の引数として "name" は実装されていません。<br>
|
||
<li><samp>No argument</samp><br>
|
||
#pragma MCPP debug, #debug の引数がありません。<br>
|
||
<li><samp>Not an identifier "123"</samp><br>
|
||
#pragma MCPP debug, #debug の引数が identifier ではありません。<br>
|
||
</ul>
|
||
<p>次は Standard モードの場合だけです。</p>
|
||
<ul>
|
||
<li><samp>"and" is defined as macro</samp><br>
|
||
C++ で and がマクロとして定義されました。
|
||
<br>
|
||
C95 では <iso646.h> でマクロとして定義される "and" 等の１１種の名前は、C++ では operator token です。C++ ではこれはマクロとして定義することができないのですが、これを operator として実装していない処理系でも使えるように、マクロとして定義することを許しながらウォーニングを出します。<br>
|
||
</ul>
|
||
<p>次は <i>STD</i> モードの場合だけです。</p>
|
||
<ul>
|
||
<li><samp>No space between macro name "MACRO" and repl-text</samp><br>
|
||
#define 行のマクロ名と置換のリストとの間にスペースがありません。通常はありえないことですが、<br>
|
||
<pre>#define THIS$AND$THAT(a, b) ((a) + (b))</pre>
|
||
というふうにマクロ名に規格外の文字が使われていると、<br>
|
||
<pre>#define THIS $AND$THAT(a, b) ((a) + (b))</pre>
|
||
と解釈されて、このウォーニングが出ます。<br>
|
||
</ul>
|
||
<p>次は lang-asm モードの場合だけです。</p>
|
||
<ul>
|
||
<li><samp>Illegal #directive "+"</samp>
|
||
<li><samp>Unknown #directive "pseudo-directive"</samp><br>
|
||
これらは lang-asm モードでなければエラーになるところですが、lang-asm モードに限ってウォーニングが出るだけです。<br>
|
||
</ul>
|
||
<p>以下の #pragma に関するウォーニングは Standard モードの場合だけです。ウォーニングは出てもその行は原則としてそのまま出力されますが、#pragma MCPP, #pragma GCC で始まる行のうち、プリプロセスで処理されるべきものは出力しません。
|
||
#pragma GCC visibility * のようにコンパイラやリンカのための行は、ウォーニングなしにそのまま出力されます。</p>
|
||
<ul>
|
||
<li><samp>No sub-directive</samp><br>
|
||
#pragma 行に何の引数もありません。この行は無視されます。<br>
|
||
<li><samp>Unknown encoding "encoding"</samp><br>
|
||
#pragma __setlocale( "encoding") で指定された "encoding" という encoding は実装していません。encoding 名については <a href=#2.8>2.8</a> を見てください。<br>
|
||
<li><samp>Too long encoding name "encoding"</samp><br>
|
||
#pragma __setlocale( "long-long-encoding") で指定された "long-long-encoding" という encoding 名は 19 バイトを超えているので、無視します。<br>
|
||
<br>
|
||
<li><samp>Bad push_macro syntax</samp><br>
|
||
<li><samp>Bad pop_macro syntax</samp><br>
|
||
#pragma MCPP push_macro, #pragma MCPP pop_macro, #pragma push_macro, #pragma pop_macro の構文が間違っています。これらの #pragma では引数はマクロ名を ", " で囲み、さらにそれを (, ) で囲んで、("MACRO") としなければなりません（Visual C 互換のための冗長な仕様である）。<br>
|
||
<li><samp>"MACRO" has not been defined</samp><br>
|
||
#pragma MCPP push_macro, #pragma MCPP pop_macro, #pragma push_macro, #pragma pop_macro の引数である ("MACRO") の MACRO はそもそもマクロとして定義されていません。<br>
|
||
<li><samp>"MACRO" is already pushed</samp><br>
|
||
#pragma MCPP push_macro( "MACRO") の MACRO はすでに push され、さらにその後で #undef されています。MACRO の再定義がないと push できません。<br>
|
||
<li><samp>"MACRO" has not been pushed</samp><br>
|
||
#pragma MCPP pop_macro( "MACRO") の MACRO は push されていません。すでに pop されたのかもしれません。<br>
|
||
</ul>
|
||
<p>GCC 版では次のウォーニングが出ます。</p>
|
||
<ul>
|
||
<li><samp>Ignored #ident</samp><br>
|
||
<li><samp>Ignored #sccs</samp><br>
|
||
#ident, #sccs の行は無視します。
|
||
<br>
|
||
</ul>
|
||
<p>ただし、GCC 用では #pragma GCC に poison, dependency のどれかが続く行は class 2 のウォーニングを出したうえで捨てます。これは GCC V.3 ではプリプロセッサが処理するものですが、<b>mcpp</b> は処理しません。</p>
|
||
<p>次は pre-Standard モードで出ます（Standard モードではエラー）。</p>
|
||
<ul>
|
||
<li><samp>Not in a #if (#ifdef) section in a source file</samp><br>
|
||
<li><samp>Line number "0x123" isn't a decimal digits sequence</samp><br>
|
||
</ul>
|
||
<p>次は <i>KR</i> モードの場合と、Standard モードの #pragma once, #pragma MCPP push_macro, #pragma MCPP pop_macro, #pragma push_macro, #pragma pop_macro, #pragma __setlocale, #pragma setlocale, #pragma MCPP put_defines, #pragma MCPP debug, #pragma MCPP end_debug の場合、および GCC 用での <i>STD</i> モードの #endif 行の場合だけ出ます（Standard モードのその他の場合はエラー、<i>OLDPREP</i> ではエラーもウォーニングも出ない）。</p>
|
||
<ul>
|
||
<li><samp>Excessive token sequence "junk"</samp><br>
|
||
</ul>
|
||
|
||
<h3><a name="5.5.4" href="#toc.5.5.4">5.5.4. #if 式に関するウォーニング</a></h3>
|
||
<p>次の３つは #if, #elif, #assert の引数に関するウォーニングです。</p>
|
||
<ul>
|
||
<li><samp>Macro "MACRO" is expanded to "defined"</samp><br>
|
||
#if 式でマクロ MACRO を展開したところ defined になりました。これは identifier ではなく演算子として扱いますが、あやしげなマクロです（Standard C では undefined）。<br>
|
||
<li><samp>Macro "MACRO" is expanded to "sizeof"</samp><br>
|
||
#if 式でマクロ MACRO を展開したところ sizeof になりました。これは identifier ではなく演算子として扱いますが、あやしげなマクロです。pre-Standard の場合です。<br>
|
||
<li><samp>Macro "MACRO" is expanded to 0 token</samp><br>
|
||
マクロ MACRO が０個のトークンに展開されました。#if 式でこれが発生すると、たいていは何らかのエラーになります。このウォーニングはエラーの原因を明らかにするためのものです。<br>
|
||
</ul>
|
||
<p>次も #if, #elif, #assert の引数に関するウォーニングですが、評価をスキップされる部分式では出ません（-W8 オプションでは出る）。</p>
|
||
<ul>
|
||
<li><samp>Undefined escape sequence '\x'</samp><br>
|
||
\x という escape sequence はありません。単なる \x という２バイトの sequence として評価します（\x に１６進文字列が続く escape sequence はもちろんある）。UCN のケタ数が足りない場合も同様です。<br>
|
||
</ul>
|
||
<p>次は #if (#elif, #assert) 行の定数式の演算と型に関するウォーニングです。やはりスキップされる部分式に関しては出ません（-W8 オプションでは出る）。</p>
|
||
<p>Standard モードでは #if 式は C90, C++98 でも long long / unsigned long long で評価します。ただし、C90, C++98 で long / unsigned long の範囲を超えた場合はウォーニングを出します。LL という suffix についても同様に、C99 以外ではウォーニングが出ます。これらのウォーニングは compiler-independent-build では class 1 で、compiler-specific-build では class 2 です。<br>
|
||
<i>POSTSTD</i> モードでは文字定数は #if 式には使えないので、ウォーニングも出ません（エラーになる）。</p>
|
||
<ul>
|
||
<li><samp>Constant "123456789012" is out of range of (unsigned) long</samp><br>
|
||
整数定数の値が (unsigned) long で表現できる範囲を超えています。<br>
|
||
<li><samp>Integer character constant 'abcde' is out of range of unsigned long</samp><br>
|
||
文字定数 'abcde' の値が unsigned long で表現できる範囲を超えています。<br>
|
||
<li><samp>Wide character constant L'abc' is out of range of unsigned long</samp><br>
|
||
ワイド文字定数 L'abc' の値が unsigned long で表現できる範囲を超えています。<br>
|
||
<li><samp>Result of "op" is out of range of (unsigned) long</samp><br>
|
||
演算子 op による演算の結果が (unsigned) long の範囲外となりました。op は２項演算子 *, /, %, +, - のどれかです。整数の内部表現が２の補数の場合は、単項 - 演算子も -<tt>LONG_MIN</tt> でオーバーフローとなります。Unsigned long はオーバーフローすることがないのでエラーにはなりませんが、代数的な演算結果が範囲外となる場合はウォーニングが出ます。<br>
|
||
<li><samp>LL suffix is used in other than C99 mode "123LL"</samp><br>
|
||
C99 以外のモードで LL という接尾子が使われています。<br>
|
||
<li><samp>Shift count "40" is larger than bit count of long</samp><br>
|
||
ビットシフト演算子 <<, >> の右 operand の値が long のビット幅を超えています。<br>
|
||
<br>
|
||
<li><samp>Negative value "-1" is converted to positive "18446744073709551615"</samp><br>
|
||
符号なしと符号つきとの混合演算の結果、符号つきの負数が符号なしの正数に変換されました。これはエラーではありませんが、たぶんソースの何らかの間違いでしょう。２項演算子 *, /, %, +, -, <, >, <=, >=, ==, !=, &, ^, | の両辺、および３項演算子 ? : の第２・第３ operand については、その片方が符号なしの場合は、他方は符号つきでも符号なしに変換されます。<br>
|
||
<li><samp>Illegal shift count "-1"</samp><br>
|
||
ビットシフト演算子 <<, >> の右 operand の値が負数です。または long long のビット幅を超えています。これもソースの間違いでしょう。<br>
|
||
<li><samp>"op" of negative number isn't portable</samp><br>
|
||
２項演算子 op の結果は、operand の一方または双方が負数である場合は portability がありません。op は /, %, >> のどれかです。左 operand が負数の場合の >> 演算子は、算術シフト命令を持つ CPU 上の処理系の間では portability があるはずですが（１ビットのシフトで２で割った結果になる）、そうでない CPU 上の処理系との間では portability がありません。<br>
|
||
</ul>
|
||
|
||
<h3><a name="5.5.5" href="#toc.5.5.5">5.5.5. マクロ展開に関するウォーニング</a></h3>
|
||
<p>これらのウォーニングではそのマクロ定義が表示され、そのマクロ定義のあるソースファイル名と行番号も表示されます。</p>
|
||
<ul>
|
||
<li><samp>Macro started at line 123 swallowed directive-like line</samp><br>
|
||
123 行から始まったマクロが # で始まる行を引数として読み込みました。たぶん、マクロ呼び出しの間違いでしょう。マクロがなければ、# で始まる行は directive line として解釈されるはずです。スキップされる #if group ではマクロがあっても展開されないので、この行は directive line として解釈されます。<br>
|
||
<li><samp>Replacement text "sub(" of macro "head" involved subsequent text</samp><br>
|
||
マクロ "head" の置換リスト "sub(" の再走査でマクロ呼び出しの後ろのテキストが取り込まれました。これは K&R 1st. から Standard C に至るまでエラーではありませんが、もし意図せずにこの種のマクロを使ってこのウォーニングが出たなら、それはマクロ定義またはマクロ呼び出しの間違いです。意図して使ったのであれば異常なマクロです。<br>
|
||
このウォーニングは <i>STD</i> モードの場合だけです。<i>COMPAT</i> モードではこのウォーニングは class 8 でしか出ません。pre-Standard モードでも同じ現象は起こりますが、ウォーニングは出ません。<i>POSTSTD</i> では再走査で置換リストの後ろのテキストは取り込まないので、このウォーニングは決して出ません（unterminated macro call のエラーになる場合と、まったく違った展開結果になる場合とある）。<br>
|
||
<li><samp>Less than necessary N argument(s) in macro call "macro( a)"</samp><br>
|
||
マクロ呼び出しの引数が足りません。通常はこれはエラーですが、可変引数マクロで引数が一つだけ足りなかった場合はウォーニングにとどめています。GCC の可変引数マクロと C99 のそれとの間の移植上の障害を減らすためです。<br>
|
||
<li><samp>Removed ',' preceding the absent variable argument</samp><br>
|
||
GCC3 仕様の可変引数マクロの呼び出しで可変引数が 0 個であるため、置換リストで可変引数の直前にあるコンマを削除しました。Standard モードの GCC-specific-build の場合だけです。<br>
|
||
<li><samp>Old style predefined macro "linux" is used</samp><br>
|
||
'_' で始まらない規格違反の事前定義マクロが使われました。
|
||
Standard モードの GCC-specific-build の場合だけです。<br>
|
||
</ul>
|
||
<p>次の２つは <i>OLDPREP</i> モードだけです（他のモードではエラー）。</p>
|
||
<ul>
|
||
<li><samp>Less than necessary N argument(s) in macro call "macro( a)"</samp><br>
|
||
<li><samp>More than necessary N argument(s) in macro call "macro( a, b, c)"</samp><br>
|
||
</ul>
|
||
|
||
<h3><a name="5.5.6" href="#toc.5.5.6">5.5.6. 行番号に関するウォーニング</a></h3>
|
||
<p>次は行番号に関するウォーニングです。</p>
|
||
<ul>
|
||
<li><samp>Line number "32768" is out of range of [1,32767]</samp><br>
|
||
C90, C++ では #line の第一引数は [1,32767] の範囲になければなりません。0 もエラーです。<tt>__STDC_VERSION__</tt> >= 199901L または <tt>__cplusplus</tt> >= 199901L の場合はこの引数の有効範囲は [1,2147483647] です。したがって、C90, C++ では [32768,2147483647] の範囲はエラーではなくウォーニングにとどめています。<br>
|
||
Standard モードの場合です。<br>
|
||
</ul>
|
||
<p>C90 では #line で 32767 よりは小さいがそれに近い番号を指定した場合、その時点ではエラーにならないものの、いずれこの範囲をオーバーします。オーバーした場合、<b>mcpp</b> では warning を出した上で行番号をそのまま増やし続けていきますが、しかし、コンパイラ本体によってはこれを受け取れないかもしれません。#line の指定がむやみに大きいことが問題です。</p>
|
||
<ul>
|
||
<li><samp>Line number 32768 got beyond range</samp><br>
|
||
ソースの行番号が 32768 に達しました。その時点で１回だけ warning が出ます。<br>
|
||
<li><samp>Line number 32769 is out of range</samp><br>
|
||
マクロ <tt>__LINE__</tt> を展開したところ、32767 を超えました。<br>
|
||
</ul>
|
||
|
||
<h3><a name="5.5.7" href="#toc.5.5.7">5.5.7. #pragma MCPP warning (#warning)</a></h3>
|
||
<ul>
|
||
<li><samp>#warning</samp><br>
|
||
<li><samp>#pragma MCPP warning</samp><br>
|
||
#pragma MCPP warning (#warning) ディレクティブが実行されました。その行が表示されます（引数そのものにトークンエラー（Unterminated string 等）があった場合は #pragma MCPP warning は実行されない）。このディレクティブは便宜上 warning level 1 のところに掲載していますが、実際には warning level に関係なく必ず表示されます。<br>
|
||
#pragma MCPP warning は Standard モードの場合で、pre-Standard モードでは #warning です。<br>
|
||
</ul>
|
||
|
||
<h2><a name="5.6" href="#toc.5.6">5.6. Warning (class 2)</a></h2>
|
||
<p>間違いではないが portability に問題のあるケースについてのウォーニングです。</p>
|
||
<ul>
|
||
<li><samp>Converted [CR+LF] to [LF]</samp><br>
|
||
改行コードを [CR+LF] から [LF] に変換しました。このウォーニングは compiler-independent-build ではクラス１で、compiler-specific-build ではクラス２です。<br>
|
||
</ul>
|
||
<p>#if 式は Standard モードでは C90, C++98 でも long long / unsigned long long で評価します。ただし、C90, C++98 で long / unsigned long の範囲を超えた場合はウォーニングを出します。LL という suffix についても同様に、C99 以外ではウォーニングが出ます。Visual C, Borland C の compiler-specific-build では I64 という suffix が使えますが、これについても同様です。これらのウォーニングは compiler-independent-build では class 1 で、compiler-specific-build では class 2 です。</p>
|
||
<ul>
|
||
<li><samp>Constant "123456789012" is out of range of (unsigned) long</samp><br>
|
||
<li><samp>Integer character constant 'abcde' is out of range of unsigned long</samp><br>
|
||
<li><samp>Wide character constant L'abc' is out of range of unsigned long</samp><br>
|
||
<li><samp>Result of "op" is out of range of (unsigned) long</samp><br>
|
||
<li><samp>LL suffix is used in other than C99 mode "123LL"</samp><br>
|
||
<li><samp>I64 suffix is used in other than C99 mode "123i64"</samp><br>
|
||
<li><samp>Shift count "40" is larger than bit count of long</samp><br>
|
||
</ul>
|
||
<p>次の５つは Standard モードの場合だけです。</p>
|
||
<ul>
|
||
<li><samp>Parsed "//" as comment</samp><br>
|
||
// から行末までをコメントとして解釈します。C99 および C++ では合法ですが、C90 でもウォーニングを出した上でコメントとして扱います。<br>
|
||
<li><samp>Variable argument macro is defined</samp><br>
|
||
可変引数マクロは C99 の仕様です。C90, C++ で可変引数マクロが定義されました。<br>
|
||
<li><samp>Empty argument in macro call "MACRO( a, ,"</samp><br>
|
||
マクロ呼び出しにカラの引数があります。<b>mcpp</b> ではその引数は０個の pp-token sequence であるとみなして reasonable な処理をします。しかし、カラ引数は C99 では合法であるものの C90 では undefined であり、portability がありません（',' さえもないのはカラ引数ではなく引数がないとみなし、エラーとする。０個の引数と１個のカラ引数とは構文上、区別がつかないが、どちらであってもエラーにはしない）。ソースにカラ引数を書くのは一般には良いスタイルではありません。可能な場合は、<br>
|
||
<pre>
|
||
#define EMPTY
|
||
</pre>
|
||
等として、この <tt>EMPTY</tt> をカラ引数の部分に書くのが良いでしょう。<br>
|
||
<li><samp>Skipped the #pragma line</samp><br>
|
||
GCC V.3 では #pragma GCC <args> という形の pragma があり、その中にはプリプロセッサが処理するものもありますが、<b>mcpp</b> は #pragma GCC poison および dependency はサポートしていません。<br>
|
||
処理系付属のプリプロセッサは処理するが <b>mcpp</b> は処理しない#pragma については、このウォーニングが出ます。<br>
|
||
<li><samp>Not a valid preprocessing token "+12"</samp><br>
|
||
## 演算子によって２つの pp-token を連結したところ、"+12" という invalid なものになりました。通常はエラーですが、-lang-asm (-x assembler-with-cpp, -a) オプションで起動された場合はエラーにはなりません。<br>
|
||
</ul>
|
||
<p>次は <i>POSTSTD</i> モードの場合だけです。</p>
|
||
<ul>
|
||
<li><samp>Header-name enclosed by <, > is an obsolescent feature <stdio.h></samp><br>
|
||
<stdio.h> という形の header name は廃止したい仕様です。"stdio.h" を使ってください。<br>
|
||
</ul>
|
||
<p>次の２つのウォーニングは特定のシステムだけのものです。それらのシステムでは正しいプログラムですが、portability がないので、念のためにウォーニングを出します。</p>
|
||
<ul>
|
||
<li><samp>#include_next is not allowed by Standard</samp><br>
|
||
<li><samp>#warning is not allowed by Standard</samp><br>
|
||
これらのディレクティブは GCC では有効ですが、規格外のものであり、portability がありません。<br>
|
||
<li><samp>GCC2-spec variadic macro is defined</samp><br>
|
||
GCC2 仕様の可変引数マクロが定義されました。
|
||
GCC-specific-build では使えますが、このマクロには portability がありません。<br>
|
||
<br>
|
||
<li><samp>Converted \ to /</samp><br>
|
||
#include directive の header name 中に \ が含まれているので、これを / に変換して処理します。これは Windows 等のＯＳでは正規の path-delimiter ですが、規定では undefined です。/ を使ったほうが間違いがありません。このウォーニングは１回しか出ません。Windows 上で動く <b>mcpp</b> だけのものです（ただし、\ が " の直前にある場合はこの " を文字列リテラルの delimiter とは解釈しないので、unterminated string literal のエラーとなる）。<br>
|
||
<li><samp>'$' in identifier "THIS$AND$THAT"</samp><br>
|
||
Identifier 中に '$' が含まれています。このウォーニングは１回しか出ません。<i>DOLLAR_IN_NAME</i> を <i>TRUE</i> にしてコンパイルされた <b>mcpp</b> でだけ出ます。それらのシステムでは '$' は identifier 中の有効な文字ですが、portability はありません。他のシステムでは '$' は１文字だけの pp-token となるので、THIS$AND$THAT は THIS $ AND $ THAT の５つの pp-token に分解されます（その結果、compile phase でエラーになるはずである）。<br>
|
||
</ul>
|
||
<br>
|
||
|
||
<h2><a name="5.7" href="#toc.5.7">5.7. Warning (class 4)</a></h2>
|
||
<p>Standard C ではいくつかの translation limits について、最低限保証すべき値を規定しています。プリプロセッサはこの値を超えた translation limits を持っているほうが仕様が良いとも言えますが、しかしそれに依存するソースは portability が制限されます。<b>mcpp</b> ではこれらの translation limits は system.H のマクロを定義することで任意に設定できるようになっていますが、Standard モードではこの値が Standard C の最小値を超えている場合は、そのことを利用するソースに対してはウォーニングを出します。しかし、処理系の標準ヘッダやソースによっては頻発する結果になるので、class 1, 2 から外してあります。</p>
|
||
<ul>
|
||
<li><samp>Logical source line longer than 509 bytes</samp><br>
|
||
ソースの論理行の長さが 509 バイトを超えています。<br>
|
||
<li><samp>Quotation longer than 509 bytes "very_very_long_string"</samp><br>
|
||
文字列リテラル、文字定数、header name の長さが 509 バイトを超えています。<br>
|
||
<li><samp>More than 8 nesting of #include</samp><br>
|
||
#include のネストが８レベルを超えました。９レベルになった時だけこのウォーニングが出ます。<br>
|
||
<li><samp>More than 8 nesting of #if (#ifdef) sections</samp><br>
|
||
#if, #ifdef, #ifndef のネストが８レベルを超えました。９レベルになった時だけこのウォーニングが出ます。<br>
|
||
<li><samp>More than 1024 macros defined</samp><br>
|
||
定義されているマクロが 1025 個に達しました。この数には pre-defined マクロも header-file で定義されたマクロも含まれています。<br>
|
||
<li><samp>String literal longer than 509 bytes "very_very_long_string"</samp><br>
|
||
# 演算子を使って定義されたマクロの展開によって、509 バイトを超える長さの文字列リテラルが生成されました。<br>
|
||
</ul>
|
||
<p>次のウォーニングはスキップされる #if group では出ません。</p>
|
||
<ul>
|
||
<li><samp>More than 32 nesting of parens in #if expression</samp><br>
|
||
#if 式のカッコのネストが３２レベルを超えました。３３レベルになった時だけ出ます。<br>
|
||
<li><samp>More than 31 parameters</samp><br>
|
||
マクロ定義のパラメータの数が３１を超えました。<br>
|
||
<li><samp>Identifier longer than 31 bytes "very_very_long_name"</samp><br>
|
||
Identifier の長さが３１バイトを超えています。<br>
|
||
</ul>
|
||
<p><tt>__STDC_VERSION__</tt> >= 199901L の場合はこれらの translation limits は次の通りです。Identifier の長さでは、UCN と multi-byte-character はそれぞれ１文字と数えます（ソースのバイト数ではない。奇妙な規定である）。</p>
|
||
<blockquote>
|
||
<table>
|
||
<tr><th>ソースの論理行の長さ </th><td>4095 バイト</td></tr>
|
||
<tr><th>文字列リテラル、文字定数、header name の長さ</th><td>4095 バイト</td></tr>
|
||
<tr><th>Identifier の長さ </th><td>63 文字</td></tr>
|
||
<tr><th>#include のネスト </th><td>15 レベル</td></tr>
|
||
<tr><th>#if, #ifdef, #ifndef のネスト </th><td>63 レベル</td></tr>
|
||
<tr><th>#if 式のカッコのネスト </th><td>63 レベル</td></tr>
|
||
<tr><th>マクロのパラメータの数 </th><td>127 個</td></tr>
|
||
<tr><th>定義できるマクロの数 </th><td>4095 個</td></tr>
|
||
</table>
|
||
</blockquote>
|
||
<p>-+ オプションで C++ のプリプロセスを指定した時は、次のような translation limits とします。ただし、マクロのパラメータの最大数は <b>mcpp</b> では 255 までしか実装できないので、256 個ではエラーとなります。</p>
|
||
<blockquote>
|
||
<table>
|
||
<tr><th>ソースの論理行の長さ </th><td>65536 バイト</td></tr>
|
||
<tr><th>文字列リテラル、文字定数、header name の長さ</th><td>65536 バイト</td></tr>
|
||
<tr><th>Identifier の長さ </th><td>1024 文字</td></tr>
|
||
<tr><th>#include のネスト </th><td>256 レベル</td></tr>
|
||
<tr><th>#if, #ifdef, #ifndef のネスト </th><td>256 レベル</td></tr>
|
||
<tr><th>#if 式のカッコのネスト </th><td>256 レベル</td></tr>
|
||
<tr><th>マクロのパラメータの数 </th><td>256 個</td></tr>
|
||
<tr><th>定義できるマクロの数 </th><td>65536 個</td></tr>
|
||
</table>
|
||
</blockquote>
|
||
<p>次のウォーニングも実際にはうるさいので、class 1, 2 から外してあります。</p>
|
||
<ul>
|
||
<li><samp>Converted 0x0c to a space</samp><br>
|
||
ソース中の token separator としての [FF], [VT], [CR] （[CR][LF] ではない単独の [CR]）のコードは space に変換します。これが directive 行にある場合は Standard C では undefined です。コメント、文字列リテラル、文字定数中のコードは変換しません（変換してもよいのであるが、文字セットは処理系依存なので、<b>mcpp</b> ではあまり制約を課さない。必要なチェックはコンパイラ本体で行われるであろう）。他方で、token separator としての [TAB] も a space に変換しますが、これはコンパイル結果に何の影響も与えないので（プリプロセッサにとってもコンパイラ本体にとっても [TAB] は space と同じ意味しか持たない）、ウォーニングは出しません。[FF] は実際のソースに時々見られるものです。「改ページ」を意図しているのでしょうが、感心しないスタイルです。<br>
|
||
<li><samp>Undefined symbol "name", evaluated to 0</samp><br>
|
||
#if 行で identifier "name" はマクロとして値が定義されていません。0 と評価します。これは決してエラーではありませんが、プログラムの間違いである可能性があります。#if defined の引数にはこのウォーニングは出ません。#if name .. とするところを #if defined name && (name ..) とするか、または <b>mcpp</b> を起動する時に -D name=0 というオプションを付けることで、このウォーニングを避けることができます。C++ では true, false というトークンは特別扱いで、ウォーニングなしにそれぞれ 1, 0 と評価します。<br>
|
||
<li><samp>Multi-character wide character constant L'ab' isn't portable</samp><br>
|
||
ワイド文字定数の値は、同じ基本文字セットの処理系間でさえもワイド文字の encoding が処理系依存であり、その上、Multi-character の評価の仕方も処理系依存なので、これを使った #if 式は移植性がありません。<i>STD</i> モードでだけ出ます。<i>POSTSTD</i> では #if 式中の文字定数は認めないのでエラーになります。次のものも同様です。<br>
|
||
<li><samp>Multi-character or multi-byte character constant '字' isn't portable</samp><br>
|
||
Multi-character character constant と multi-byte character character constant の値の評価の仕方は処理系依存なので、これを使った #if 式は移植性がありません。<i>STD</i> モードで出ます。<br>
|
||
</ul>
|
||
<p>次の２つは Standard モードの場合だけ出ます。</p>
|
||
<ul>
|
||
<li><samp>Macro with mixing of ## and # operators isn't portable</samp><br>
|
||
関数様マクロ定義の置換リスト中に ## # というトークンの並びがありますが、この２つの演算子の優先順位は Standard C では unspecified なので、移植性がありません。<b>mcpp</b> では # を先に適用します。なお、関数様マクロ定義で逆向きの # ## というトークンの並びがあるとエラーになります。# 演算子のオペランドはパラメータでなければならないからです。<br>
|
||
<li><samp>Macro with multiple ## operators isn't portable</samp><br>
|
||
マクロ定義の置換リスト中に複数の ## 演算子が間に１つのトークンまたはパラメータだけをはさんでありますが、## 演算子の評価順序は Standard C では unspecified なので、このマクロは移植性のない場合があります。<b>mcpp</b> では ## 演算子は左から右へ順に適用していきます。<br>
|
||
</ul>
|
||
<p>次は <i>STD</i> モードで -k または -K オプションを指定したときだけのものです。</p>
|
||
<ul>
|
||
<li><samp>Too long comment, discarded up to here</samp><br>
|
||
コメントが極端に長いので、ここまでの部分を割愛します。
|
||
行をまたぐコメントが 256 行以上になると、そこまでを捨てて、次行を１行目としてカウントします。
|
||
長大なドキュメントをソースに含めるのは、良いスタイルではありません。<br>
|
||
</ul>
|
||
<br>
|
||
|
||
<h2><a name="5.8" href="#toc.5.8">5.8. Warning (class 8)</a></h2>
|
||
<p>ソースの間違いである可能性は少ないが念のために注意を促す意味で、このメッセージが出ます。これをチェックするのは -W8 のオプションで起動された場合だけです。</p>
|
||
<p>スキップされる #if group の中の preprocessing directive は通常は #if, #ifdef, #ifndef, #elif, #else, #endif の対応関係しかチェックしませんが、-W8 では Illegal directive, Unknown directive のチェックもします。また、Standard モードでは #if のネストが８レベルを超えた場合もウォーニングを出します。</p>
|
||
<ul>
|
||
<li><samp>Illegal #directive "+" (in skipped block)</samp><br>
|
||
<li><samp>Unknown #directive "pseudo-directive" (in skipped block)</samp><br>
|
||
<li><samp>Ignored #ident (in skipped block)</samp><br>
|
||
<li><samp>Ignored #sccs (in skipped block)</samp><br>
|
||
<li><samp>More than 8 nesting of #if (#ifdef) sections (in skipped block)</samp><br>
|
||
<li><samp>#include_next is not allowed by Standard (in skipped block)</samp><br>
|
||
<li><samp>#warning is not allowed by Standard (in skipped block)</samp><br>
|
||
</ul>
|
||
<p>次は #if 式に関するウォーニングです。例えば #if a || b という式では、a が真であれば b の評価は行われません。しかし、-W8 として起動すると、評価されない部分式に関してもこれらのウォーニングが出されます。この場合はいずれも (in non-evaluated sub-expression) というただし書きが付けられます。</p>
|
||
<ul>
|
||
<li><samp>Constant "123456789012345678901" is out of range</samp><br>
|
||
<li><samp>Constant "123456789012" is out of range of (unsigned) long</samp><br>
|
||
<li><samp>LL suffix is used in other than C99 mode "123LL"</samp><br>
|
||
<li><samp>I64 suffix is used in other than C99 mode "123i64"</samp><br>
|
||
<li><samp>Shift count "40" is larger than bit count of long</samp><br>
|
||
<li><samp>Integer character constant 'abcdefghi' is out of range</samp><br>
|
||
<li><samp>Integer character constant 'abcde' is out of range of unsigned long</samp><br>
|
||
<li><samp>Wide character constant L'abcdef' is out of range</samp><br>
|
||
<li><samp>Wide character constant L'abc' is out of range of unsigned long</samp><br>
|
||
<li><samp>8 bits can't represent escape sequence 'x123'</samp><br>
|
||
<li><samp>16 bits can't represent escape sequence L'x12345'</samp><br>
|
||
<li><samp>Division by zero</samp><br>
|
||
<li><samp>Undefined symbol "name", evaluated to 0</samp><br>
|
||
<li><samp>sizeof: Unknown type "type"</samp><br>
|
||
<li><samp>sizeof: Illegal type combination with "type"</samp><br>
|
||
<li><samp>Multi-character wide character constant L'ab' isn't portable</samp><br>
|
||
<li><samp>Multi-character or multi-byte character constant '字' isn't portable</samp><br>
|
||
<li><samp>Undefined escape sequence '\x'</samp><br>
|
||
<li><samp>UCN cannot specify the value "0000007f"</samp><br>
|
||
<li><samp>Negative value "-1" is converted to positive "18446744073709551615"</samp><br>
|
||
<li><samp>Result of "op" is out of range</samp><br>
|
||
<li><samp>Result of "op" is out of range of (unsigned) long</samp><br>
|
||
<li><samp>Illegal shift count "-1"</samp><br>
|
||
<li><samp>"op" of negative number isn't portable</samp><br>
|
||
<br>
|
||
<li><samp>sizeof is disallowed in C Standard</samp><br>
|
||
#if sizeof が実装されるのは pre-Standard モードだけですが、その場合でもこれは Standard C では使えませんよというお節介をします。<br>
|
||
<li><samp>"MACRO" wasn't defined</samp><br>
|
||
#undef に定義されていない名前を指定しています。これは少なくとも Standard C ではエラーではありません。<br>
|
||
<li><samp>Macro "macro" needs arguments</samp><br>
|
||
引数付きマクロとして定義されているものと同じ名前が単独で現れています。展開せず、そのまま残します。pre-Standard モードの場合だけ出ます（Standard モードでは何ら問題ないので、ウォーニングは出ない）。<br>
|
||
<li><samp>Replacement text "sub(" of macro "head" involved subsequent text</samp><br>
|
||
マクロ "head" の置換リスト "sub(" の再走査でマクロ呼び出しの後ろのテキストが取り込まれました。このウォーニングは <i>STD</i> モードでは class 1 ですが、<i>COMPAT</i> モードでは class 8 です。<br>
|
||
</ul>
|
||
<br>
|
||
|
||
<h2><a name="5.9" href="#toc.5.9">5.9. Warning (class 16)</a></h2>
|
||
<p>Trigraph と digraph は使う必要のない環境ではまったく使わないものです。その環境でもしこれらが検出されれば、注意を要するでしょう。-W16 オプションはこれを検出するものです。他方で、trigraph あるいは digraph が常用されているソースではこのウォーニングが頻発することになってうるさいでしょうから、これを他のウォーニングとは別のクラスにしてあります。どちらにしても、これらは trigraph あるいは digraph が有効な状態でだけ検出されます。Digraph は Standard モードの場合で、trigraph は <i>STD</i> モードだけです。</p>
|
||
<ul>
|
||
<li><samp>2 trigraph(s) converted</samp><br>
|
||
この物理行中の２つの trigraph sequence を変換しました。本当に trigraph のつもりで書いたのでしょうか？<br>
|
||
<li><samp>2 digraph(s) converted</samp><br>
|
||
この行中の２つの digraph sequence を変換しました。本当に digraph のつもりで書いたのでしょうか？<br>
|
||
<i>STD</i> モードでは digraph 処理のできない処理系では、プリプロセスが終わってから digraph を次のように通常の token に変換して出力します。<br>
|
||
<pre>
|
||
<% -> { <: -> [ %: -> #
|
||
%> -> } :> -> [ %:%: -> ##
|
||
</pre>
|
||
しかし、<i>POSTSTD</i> モードでは translation phase 1 で通常の pp-token に変換してしまいます。この違いは、digraph が # 演算子による文字列化の対象になった時に現れます。デフォルトでは digraph sequence のまま文字列化しますが、<i>POSTSTD</i> では通常の pp-token に変換されたものが文字列化されます。また、文字列リテラルの中に digraph sequence に相当する character sequence があった場合、デフォルトではそのままですが、<i>POSTSTD</i> ではこれも対応する pp-token の character sequence に変換されます。<br>
|
||
<i>STD</i> モードではこのウォーニングは digraph の「変換」を対象としているので、preprocessing-directive 行に現れて消えてしまう digraph はカウントされません。<br>
|
||
</ul>
|
||
<br>
|
||
|
||
<h2><a name="5.10" href="#toc.5.10">5.10. 診断メッセージ索引</a></h2>
|
||
<table border='1' frame='below'><tr><th rowspan='2'>診断メッセージ</th><th rowspan='2'>Fatal<br>error</th><th rowspan='2'>Error</th><th colspan='5'>Warning class</th></tr>
|
||
<th>1</th><th>2</th><th>4</th><th>8</th><th>16</th></tr>
|
||
<tr><td><samp>"..." isn't the last parameter</samp></td><td></td><td><a href='#5.4.7'>5.4.7</td></tr>
|
||
<tr><td><samp>"/*" in comment</samp></td><td></td><td></td><td><a href='#5.5.1'>5.5.1</td></tr>
|
||
<tr><td><samp>"and" is defined as macro</samp></td><td></td><td></td><td><a href='#5.5.3'>5.5.3</td></tr>
|
||
<tr><td><samp>"defined" shouldn't be defined</samp></td><td></td><td><a href='#5.4.7'>5.4.7</td></tr>
|
||
<tr><td><samp>"MACRO" has not been defined</samp></td><td></td><td></td><td><a href='#5.5.3'>5.5.3</td></tr>
|
||
<tr><td><samp>"MACRO" has not been pushed</samp></td><td></td><td></td><td><a href='#5.5.3'>5.5.3</td></tr>
|
||
<tr><td><samp>"MACRO" is already pushed</samp></td><td></td><td></td><td><a href='#5.5.3'>5.5.3</td></tr>
|
||
<tr><td><samp>"MACRO" wasn't defined</samp></td><td></td><td></td><td></td><td></td><td></td><td><a href='#5.8'>5.8</td></tr>
|
||
<tr><td><samp>"op" of negative number isn't portable</samp></td><td></td><td></td><td><a href='#5.5.4'>5.5.4</td><td></td><td></td><td><a href='#5.8'>5.8</td></tr>
|
||
<tr><td><samp>"__STDC__" shouldn't be redefined</samp></td><td></td><td><a href='#5.4.7'>5.4.7</td></tr>
|
||
<tr><td><samp>"__STDC__" shouldn't be undefined</samp></td><td></td><td><a href='#5.4.8'>5.4.8</td></tr>
|
||
<tr><td><samp>"__VA_ARGS__" without corresponding "..."</samp></td><td></td><td><a href='#5.4.7'>5.4.7</td></tr>
|
||
<tr><td><samp>"__VA_ARGS__" cannot be used in GCC2-spec variadic macro</samp></td><td></td><td><a href='#5.4.7'>5.4.7</td></tr>
|
||
<tr><td><samp>## after ##</samp></td><td></td><td><a href='#5.4.7'>5.4.7</td></tr>
|
||
<tr><td><samp>#error</samp></td><td></td><td><a href='#5.4.10'>5.4.10</td></tr>
|
||
<tr><td><samp>#include_next is not allowed by Standard</samp></td><td></td><td></td><td></td><td><a href='#5.6'>5.6</td><td></td><td><a href='#5.8'>5.8</td></tr>
|
||
<tr><td><samp>#warning</samp></td><td></td><td></td><td><a href='#5.5.7'>5.5.7</td></tr>
|
||
<tr><td><samp>'$' in identifier "THIS$AND$THAT"</samp></td><td></td><td></td><td></td><td><a href='#5.6'>5.6</td></tr>
|
||
<tr><td><samp>16 bits can't represent escape sequence L'\x12345'</samp></td><td></td><td><a href='#5.4.6'>5.4.6</td><td></td><td></td><td></td><td><a href='#5.8'>5.8</td></tr>
|
||
<tr><td><samp>2 digraph(s) converted</samp></td><td></td><td></td><td></td><td></td><td></td><td></td><td><a href='#5.9'>5.9</td></tr>
|
||
<tr><td><samp>2 trigraph(s) converted</samp></td><td></td><td></td><td></td><td></td><td></td><td></td><td><a href='#5.9'>5.9</td></tr>
|
||
<tr><td><samp>8 bits can't represent escape sequence '\x123'</samp></td><td></td><td><a href='#5.4.6'>5.4.6</td><td></td><td></td><td></td><td><a href='#5.8'>5.8</td></tr>
|
||
<tr><td><samp>_Pragma operator found in directive line</samp></td><td></td><td><a href='#5.4.12'>5.4.12</td></tr>
|
||
<tr><td><samp>Already seen #else at line 123</samp></td><td></td><td><a href='#5.4.3'>5.4.3</td></tr>
|
||
<tr><td><samp>Bad defined syntax</samp></td><td></td><td><a href='#5.4.5'>5.4.5</td></tr>
|
||
<tr><td><samp>Bad pop_macro syntax</samp></td><td></td><td></td><td><a href='#5.5.3'>5.5.3</td></tr>
|
||
<tr><td><samp>Bad push_macro syntax</samp></td><td></td><td></td><td><a href='#5.5.3'>5.5.3</td></tr>
|
||
<tr><td><samp>Buffer overflow expanding macro "macro" at "something"</samp></td><td></td><td><a href='#5.4.9'>5.4.9</td></tr>
|
||
<tr><td><samp>Buffer overflow scanning token "token"</samp></td><td><a href='#5.3.3'>5.3.3</td></tr>
|
||
<tr><td><samp>Bug:</samp></td><td><a href='#5.3.1'>5.3.1</td></tr>
|
||
<tr><td><samp>Can't open include file "file-name"</samp></td><td></td><td><a href='#5.4.11'>5.4.11</td></tr>
|
||
<tr><td><samp>Can't use a character constant 'a'</samp></td><td></td><td><a href='#5.4.5'>5.4.5</td></tr>
|
||
<tr><td><samp>Can't use a string literal "string"</samp></td><td></td><td><a href='#5.4.5'>5.4.5</td></tr>
|
||
<tr><td><samp>Can't use the character 0x24</samp></td><td></td><td><a href='#5.4.5'>5.4.5</td></tr>
|
||
<tr><td><samp>Can't use the operator "++"</samp></td><td></td><td><a href='#5.4.5'>5.4.5</td></tr>
|
||
<tr><td><samp>Constant "123456789012" is out of range of (unsigned) long</samp></td><td></td><td></td><td><a href='#5.5.4'>5.5.4</td><td><a href='#5.6'>5.6</td><td></td><td><a href='#5.8'>5.8</td></tr>
|
||
<tr><td><samp>Constant "1234567890123456789012" is out of range</samp></td><td></td><td><a href='#5.4.6'>5.4.6</td><td></td><td></td><td></td><td><a href='#5.8'>5.8</td></tr>
|
||
<tr><td><samp>Converted 0x0c to a space</samp></td><td></td><td></td><td></td><td></td><td><a href='#5.7'>5.7</td></tr>
|
||
<tr><td><samp>Converted [CR+LF] to [LF]</samp></td><td></td><td></td><td><a href='#5.5.1'>5.5.1</td><td><a href='#5.6'>5.6</td></tr>
|
||
<tr><td><samp>Converted \ to /</samp></td><td></td><td></td><td></td><td><a href='#5.6'>5.6</td></tr>
|
||
<tr><td><samp>Division by zero</samp></td><td></td><td><a href='#5.4.6'>5.4.6</td><td></td><td></td><td></td><td><a href='#5.8'>5.8</td></tr>
|
||
<tr><td><samp>Duplicate parameter names "a"</samp></td><td></td><td><a href='#5.4.7'>5.4.7</td></tr>
|
||
<tr><td><samp>Empty argument in macro call "MACRO( a, ,"</samp></td><td></td><td></td><td></td><td><a href='#5.6'>5.6</td></tr>
|
||
<tr><td><samp>Empty character constant ''</samp></td><td></td><td><a href='#5.4.1'>5.4.1</td><td><a href='#5.5.1'>5.5.1</td></tr>
|
||
<tr><td><samp>Empty parameter</samp></td><td></td><td><a href='#5.4.7'>5.4.7</td></tr>
|
||
<tr><td><samp>End of file with no newline, supplemented the newline</samp></td><td></td><td></td><td><a href='#5.5.2'>5.5.2</td></tr>
|
||
<tr><td><samp>End of file with unterminated #asm block started at line 123</samp></td><td></td><td><a href='#5.4.2'>5.4.2</td><td><a href='#5.5.2'>5.5.2</td></tr>
|
||
<tr><td><samp>End of file with unterminated comment, terminated the comment</samp></td><td></td><td></td><td><a href='#5.5.2'>5.5.2</td></tr>
|
||
<tr><td><samp>End of file with \, deleted the \</samp></td><td></td><td></td><td><a href='#5.5.2'>5.5.2</td></tr>
|
||
<tr><td><samp>End of file within #if (#ifdef) section started at line 123</samp></td><td></td><td><a href='#5.4.2'>5.4.2</td><td><a href='#5.5.2'>5.5.2</td></tr>
|
||
<tr><td><samp>End of file within macro call started at line 123</samp></td><td></td><td><a href='#5.4.2'>5.4.2</td><td><a href='#5.5.2'>5.5.2</td></tr>
|
||
<tr><td><samp>Excessive ")"</samp></td><td></td><td><a href='#5.4.5'>5.4.5</td></tr>
|
||
<tr><td><samp>Excessive token sequence "junk"</samp></td><td></td><td><a href='#5.4.4'>5.4.4</td><td><a href='#5.5.3'>5.5.3</td></tr>
|
||
<tr><td><samp>File read error</samp></td><td><a href='#5.3.2'>5.3.2</td></tr>
|
||
<tr><td><samp>File write error</samp></td><td><a href='#5.3.2'>5.3.2</td></tr>
|
||
<tr><td><samp>Header-name enclosed by <, > is an obsolescent feature <stdio.h></samp></td><td></td><td></td><td></td><td><a href='#5.6'>5.6</td></tr>
|
||
<tr><td><samp>GCC2-spec variadic macro is defined</samp></td><td></td><td></td><td></td><td><a href='#5.6'>5.6</td></tr>
|
||
<tr><td><samp>I64 suffix is used in other than C99 mode "123i64"</samp></td><td></td><td></td><td></td><td><a href='#5.6'>5.6</td><td></td><td><a href='#5.8'>5.8</td></tr>
|
||
<tr><td><samp>Identifier longer than 31 bytes "very_very_long_name"</samp></td><td></td><td></td><td></td><td></td><td><a href='#5.7'>5.7</td></tr>
|
||
<tr><td><samp>Ignored #ident</samp></td><td></td><td></td><td><a href='#5.5.3'>5.5.3</td><td></td><td></td><td><a href='#5.8'>5.8</td></tr>
|
||
<tr><td><samp>Ignored #sccs</samp></td><td></td><td></td><td><a href='#5.5.3'>5.5.3</td><td></td><td></td><td><a href='#5.8'>5.8</td></tr>
|
||
<tr><td><samp>Illegal #directive "123"</samp></td><td></td><td><a href='#5.4.4'>5.4.4</td><td><a href='#5.5.3'>5.5.3</td><td></td><td></td><td><a href='#5.8'>5.8</td></tr>
|
||
<tr><td><samp>Illegal control character 0x1b in quotation</samp></td><td></td><td></td><td><a href='#5.5.1'>5.5.1</td></tr>
|
||
<tr><td><samp>Illegal control character 0x1b, skipped the character</samp></td><td></td><td><a href='#5.4.1'>5.4.1</td></tr>
|
||
<tr><td><samp>Illegal digit in octal number "089"</samp></td><td></td><td></td><td><a href='#5.5.1'>5.5.1</td></tr>
|
||
<tr><td><samp>Illegal multi-byte character sequence "XY" in quotation</samp></td><td></td><td></td><td><a href='#5.5.1'>5.5.1</td></tr>
|
||
<tr><td><samp>Illegal multi-byte character sequence "XY"</samp></td><td></td><td><a href='#5.4.1'>5.4.1</td></tr>
|
||
<tr><td><samp>Illegal parameter "123"</samp></td><td></td><td><a href='#5.4.7'>5.4.7</td></tr>
|
||
<tr><td><samp>Illegal shift count "-1"</samp></td><td></td><td></td><td><a href='#5.5.4'>5.5.4</td><td></td><td></td><td><a href='#5.8'>5.8</td></tr>
|
||
<tr><td><samp>Illegal UCN sequence</samp></td><td></td><td><a href='#5.4.1'>5.4.1</td></tr>
|
||
<tr><td><samp>In #asm block started at line 123</samp></td><td></td><td><a href='#5.4.3'>5.4.3</td></tr>
|
||
<tr><td><samp>Integer character constant 'abcde' is out of range of unsigned long</samp></td><td></td><td></td><td><a href='#5.5.4'>5.5.4</td><td><a href='#5.6'>5.6</td><td></td><td><a href='#5.8'>5.8</td></tr>
|
||
<tr><td><samp>Integer character constant 'abcdefghi' is out of range</samp></td><td></td><td><a href='#5.4.6'>5.4.6</td><td></td><td></td><td></td><td><a href='#5.8'>5.8</td></tr>
|
||
<tr><td><samp>Less than necessary N argument(s) in macro call "macro( a)"</samp></td><td></td><td><a href='#5.4.9'>5.4.9</td><td><a href='#5.5.5'>5.5.5</td></tr>
|
||
<tr><td><samp>Line number "0x123" isn't a decimal digits sequence</samp></td><td></td><td><a href='#5.4.4'>5.4.4</td><td><a href='#5.5.6'>5.5.6</td></tr>
|
||
<tr><td><samp>Line number "2147483648" is out of range of 1,2147483647</samp></td><td></td><td><a href='#5.4.4'>5.4.4</td></tr>
|
||
<tr><td><samp>Line number "32768" got beyond range</samp></td><td></td><td></td><td><a href='#5.5.6'>5.5.6</td></tr>
|
||
<tr><td><samp>Line number "32768" is out of range of 1,32767</samp></td><td></td><td></td><td><a href='#5.5.6'>5.5.6</td></tr>
|
||
<tr><td><samp>Line number "32769" is out of range</samp></td><td></td><td></td><td><a href='#5.5.6'>5.5.6</td></tr>
|
||
<tr><td><samp>LL suffix is used in other than C99 mode "123LL"</samp></td><td></td><td></td><td><a href='#5.5.4'>5.5.4</td><td><a href='#5.6'>5.6</td><td></td><td><a href='#5.8'>5.8</td></tr>
|
||
<tr><td><samp>Logical source line longer than 509 bytes</samp></td><td></td><td></td><td></td><td></td><td><a href='#5.7'>5.7</td></tr>
|
||
<tr><td><samp>Macro "MACRO" is expanded to "defined"</samp></td><td></td><td></td><td><a href='#5.5.4'>5.5.4</td></tr>
|
||
<tr><td><samp>Macro "MACRO" is expanded to "sizeof"</samp></td><td></td><td></td><td><a href='#5.5.4'>5.5.4</td></tr>
|
||
<tr><td><samp>Macro "MACRO" is expanded to 0 token</samp></td><td></td><td></td><td><a href='#5.5.4'>5.5.4</td></tr>
|
||
<tr><td><samp>Macro "macro" needs arguments</samp></td><td></td><td></td><td></td><td></td><td></td><td><a href='#5.8'>5.8</td></tr>
|
||
<tr><td><samp>Macro started at line 123 swallowed directive-like line</samp></td><td></td><td></td><td><a href='#5.5.5'>5.5.5</td></tr>
|
||
<tr><td><samp>Macro with mixing of ## and # operators isn't portable</samp></td><td></td><td></td><td></td><td></td><td><a href='#5.7'>5.7</td></tr>
|
||
<tr><td><samp>Macro with multiple ## operators isn't portable</samp></td><td></td><td></td><td></td><td></td><td><a href='#5.7'>5.7</td></tr>
|
||
<tr><td><samp>Misplaced ":", previous operator is "+"</samp></td><td></td><td><a href='#5.4.5'>5.4.5</td></tr>
|
||
<tr><td><samp>Misplaced constant "12"</samp></td><td></td><td><a href='#5.4.5'>5.4.5</td></tr>
|
||
<tr><td><samp>Missing ")"</samp></td><td></td><td><a href='#5.4.5'>5.4.5</td></tr>
|
||
<tr><td><samp>Missing "," or ")" in parameter list "(a,b"</samp></td><td></td><td><a href='#5.4.7'>5.4.7</td></tr>
|
||
<tr><td><samp>More than 1024 macros defined</samp></td><td></td><td></td><td></td><td></td><td><a href='#5.7'>5.7</td></tr>
|
||
<tr><td><samp>More than 31 parameters</samp></td><td></td><td></td><td></td><td></td><td><a href='#5.7'>5.7</td></tr>
|
||
<tr><td><samp>More than 32 nesting of parens in #if expression</samp></td><td></td><td></td><td></td><td></td><td><a href='#5.7'>5.7</td></tr>
|
||
<tr><td><samp>More than 8 nesting of #if (#ifdef) sections</samp></td><td></td><td></td><td></td><td></td><td><a href='#5.7'>5.7</td><td><a href='#5.8'>5.8</td></tr>
|
||
<tr><td><samp>More than 8 nesting of #include</samp></td><td></td><td></td><td></td><td></td><td><a href='#5.7'>5.7</td></tr>
|
||
<tr><td><samp>More than <i>BLK_NEST</i> nesting of #if (#ifdef) sections</samp></td><td><a href='#5.3.3'>5.3.3</td></tr>
|
||
<tr><td><samp>More than <i>INCLUDE_NEST</i> nesting of #include</samp></td><td><a href='#5.3.3'>5.3.3</td></tr>
|
||
<tr><td><samp>More than necessary N argument(s) in macro call "macro( a, b, c)</samp></td><td></td><td><a href='#5.4.9'>5.4.9</td></tr>
|
||
<tr><td><samp>More than <i>NEXP</i>*2-1 constants stacked at "12"</samp></td><td></td><td><a href='#5.4.5'>5.4.5</td></tr>
|
||
<tr><td><samp>More than <i>NEXP</i>*3-1 operators and parens stacked at "+"</samp></td><td></td><td><a href='#5.4.5'>5.4.5</td></tr>
|
||
<tr><td><samp>More than <i>NMACPARS</i> parameters</samp></td><td></td><td><a href='#5.4.7'>5.4.7</td></tr>
|
||
<tr><td><samp>Multi-character or multi-byte character constant '字' isn't portable</samp></td><td></td><td></td><td></td><td></td><td><a href='#5.7'>5.7</td><td><a href='#5.8'>5.8</td></tr>
|
||
<tr><td><samp>Multi-character wide character constant L'ab' isn't portable</samp></td><td></td><td></td><td></td><td></td><td><a href='#5.7'>5.7</td><td><a href='#5.8'>5.8</td></tr>
|
||
<tr><td><samp>Negative value "-1" is converted to positive "18446744073709551615"</samp></td><td></td><td></td><td><a href='#5.5.4'>5.5.4</td><td></td><td></td><td><a href='#5.8'>5.8</td></tr>
|
||
<tr><td><samp>No argument</samp></td><td></td><td><a href='#5.4.4'>5.4.4</td><td><a href='#5.5.3'>5.5.3</td></tr>
|
||
<tr><td><samp>No header name</samp></td><td></td><td><a href='#5.4.4'>5.4.4</td></tr>
|
||
<tr><td><samp>No identifier</samp></td><td></td><td><a href='#5.4.4'>5.4.4</td></tr>
|
||
<tr><td><samp>No line number</samp></td><td></td><td><a href='#5.4.4'>5.4.4</td></tr>
|
||
<tr><td><samp>No space between macro name "MACRO" and repl-text</samp></td><td></td><td></td><td><a href='#5.5.3'>5.5.3</td></tr>
|
||
<tr><td><samp>No sub-directive</samp></td><td></td><td></td><td><a href='#5.5.3'>5.5.3</td></tr>
|
||
<tr><td><samp>No token after ##</samp></td><td></td><td><a href='#5.4.7'>5.4.7</td></tr>
|
||
<tr><td><samp>No token before ##</samp></td><td></td><td><a href='#5.4.7'>5.4.7</td></tr>
|
||
<tr><td><samp>Not a file name "name"</samp></td><td></td><td><a href='#5.4.4'>5.4.4</td></tr>
|
||
<tr><td><samp>Not a formal parameter "id"</samp></td><td></td><td><a href='#5.4.7'>5.4.7</td></tr>
|
||
<tr><td><samp>Not a header name "UNDEFINED_MACRO"</samp></td><td></td><td><a href='#5.4.4'>5.4.4</td></tr>
|
||
<tr><td><samp>Not a line number "name"</samp></td><td></td><td><a href='#5.4.4'>5.4.4</td></tr>
|
||
<tr><td><samp>Not a valid preprocessing token "+12"</samp></td><td></td><td><a href='#5.4.9'>5.4.9</td><td></td><td><a href='#5.6'>5.6</td></tr>
|
||
<tr><td><samp>Not a valid string literal</samp></td><td></td><td><a href='#5.4.9'>5.4.9</td></tr>
|
||
<tr><td><samp>Not an identifier "123"</samp></td><td></td><td><a href='#5.4.4'>5.4.4</td><td><a href='#5.5.3'>5.5.3</td></tr>
|
||
<tr><td><samp>Not an integer "1.23"</samp></td><td></td><td><a href='#5.4.5'>5.4.5</td></tr>
|
||
<tr><td><samp>Not in a #if (#ifdef) section</samp></td><td></td><td><a href='#5.4.3'>5.4.3</td></tr>
|
||
<tr><td><samp>Not in a #if (#ifdef) section in a source file</samp></td><td></td><td><a href='#5.4.3'>5.4.3</td><td><a href='#5.5.3'>5.5.3</td></tr>
|
||
<tr><td><samp>Old style predefined macro "linux" is used</samp></td><td></td><td></td><td><a href='#5.5.5'>5.5.5</td></tr>
|
||
<tr><td><samp>Operand of _Pragma() is not a string literal</samp></td><td></td><td><a href='#5.4.12'>5.4.12</td></tr>
|
||
<tr><td><samp>Operator ">" in incorrect context</samp></td><td></td><td><a href='#5.4.5'>5.4.5</td></tr>
|
||
<tr><td><samp>Out of memory (required size is 0x1234 bytes)</samp></td><td><a href='#5.3.2'>5.3.2</td></tr>
|
||
<tr><td><samp>Parsed "//" as comment</samp></td><td></td><td></td><td></td><td><a href='#5.6'>5.6</td></tr>
|
||
<tr><td><samp>Preprocessing assertion failed</samp></td><td></td><td><a href='#5.4.10'>5.4.10</td></tr>
|
||
<tr><td><samp>Quotation longer than 509 bytes "very_very_long_string"</samp></td><td></td><td></td><td></td><td></td><td><a href='#5.7'>5.7</td></tr>
|
||
<tr><td><samp>Recursive macro definition of "macro" to "macro"</samp></td><td></td><td><a href='#5.4.9'>5.4.9</td></tr>
|
||
<tr><td><samp>Removed ',' preceding the absent variable argument</samp></td><td></td><td></td><td><a href='#5.5.5'>5.5.5</td></tr>
|
||
<tr><td><samp>Replacement text "sub(" of macro "head" involved subsequent text</samp></td><td></td><td></td><td><a href='#5.5.5'>5.5.5</td><td></td><td></td><td><a href='#5.8'>5.8</td></tr>
|
||
<tr><td><samp>Rescanning macro "macro" more than <i>RESCAN_LIMIT</i> times at "something"</samp></td><td></td><td><a href='#5.4.9'>5.4.9</td></tr>
|
||
<tr><td><samp>Result of "op" is out of range</samp></td><td></td><td><a href='#5.4.6'>5.4.6</td><td></td><td></td><td></td><td><a href='#5.8'>5.8</td></tr>
|
||
<tr><td><samp>Result of "op" is out of range of (unsigned) long</samp></td><td></td><td></td><td><a href='#5.5.4'>5.5.4</td><td><a href='#5.6'>5.6</td><td></td><td><a href='#5.8'>5.8</td></tr>
|
||
<tr><td><samp>Shift count "40" is larger than bit count of long</samp></td><td></td><td></td><td><a href='#5.5.4'>5.5.4</td><td><a href='#5.6'>5.6</td><td></td><td><a href='#5.8'>5.8</td></tr>
|
||
<tr><td><samp>sizeof is disallowed in C Standard</samp></td><td></td><td></td><td></td><td></td><td></td><td><a href='#5.8'>5.8</td></tr>
|
||
<tr><td><samp>sizeof: Illegal type combination with "type"</samp></td><td></td><td><a href='#5.4.6'>5.4.6</td><td></td><td></td><td></td><td><a href='#5.8'>5.8</td></tr>
|
||
<tr><td><samp>sizeof: No type specified</samp></td><td></td><td><a href='#5.4.5'>5.4.5</td></tr>
|
||
<tr><td><samp>sizeof: Syntax error</samp></td><td></td><td><a href='#5.4.5'>5.4.5</td></tr>
|
||
<tr><td><samp>sizeof: Unknown type "type"</samp></td><td></td><td><a href='#5.4.6'>5.4.6</td><td></td><td></td><td></td><td><a href='#5.8'>5.8</td></tr>
|
||
<tr><td><samp>Skipped the #pragma line</samp></td><td></td><td></td><td></td><td><a href='#5.6'>5.6</td></tr>
|
||
<tr><td><samp>String literal longer than 509 bytes "very_very_long_string"</samp></td><td></td><td></td><td></td><td></td><td><a href='#5.7'>5.7</td></tr>
|
||
<tr><td><samp>The macro is redefined</samp></td><td></td><td></td><td><a href='#5.5.4'>5.5.4</td></tr>
|
||
<tr><td><samp>This is not a preprocessed source</samp></td><td><a href='#5.3.4'>5.3.4</td></tr>
|
||
<tr><td><samp>This preprocessed file is corrupted</samp></td><td><a href='#5.3.4'>5.3.4</td></tr>
|
||
<tr><td><samp>Too long comment, discarded up to here</samp></td><td></td><td></td><td></td><td></td><td><a href='#5.7'>5.7</td></tr>
|
||
<tr><td><samp>Too long header name "long-file-name"</samp></td><td><a href='#5.3.3'>5.3.3</td></tr>
|
||
<tr><td><samp>Too long identifier, truncated to "very_long_identifier"</samp></td><td></td><td></td><td><a href='#5.5.1'>5.5.1</td></tr>
|
||
<tr><td><samp>Too long line spliced by comments</samp></td><td><a href='#5.3.3'>5.3.3</td></tr>
|
||
<tr><td><samp>Too long logical line</samp></td><td><a href='#5.3.3'>5.3.3</td></tr>
|
||
<tr><td><samp>Too long number token "12345678901234"</samp></td><td><a href='#5.3.3'>5.3.3</td></tr>
|
||
<tr><td><samp>Too long pp-number token "1234toolong"</samp></td><td><a href='#5.3.3'>5.3.3</td></tr>
|
||
<tr><td><samp>Too long quotation "long-string"</samp></td><td><a href='#5.3.3'>5.3.3</td></tr>
|
||
<tr><td><samp>Too long source line</samp></td><td><a href='#5.3.3'>5.3.3</td></tr>
|
||
<tr><td><samp>Too long token</samp></td><td><a href='#5.3.3'>5.3.3</td></tr>
|
||
<tr><td><samp>Too many magics nested in macro argument</samp></td><td></td><td><a href='#5.4.9'>5.4.9</td></tr>
|
||
<tr><td><samp>Too many nested macros in tracing MACRO</samp></td><td></td><td><a href='#5.4.9'>5.4.9</td></tr>
|
||
<tr><td><samp>UCN cannot specify the value "0000007f"</samp></td><td></td><td><a href='#5.4.1'>5.4.1</td><td></td><td></td><td></td><td><a href='#5.8'>5.8</td></tr>
|
||
<tr><td><samp>Undefined escape sequence '\x'</samp></td><td></td><td></td><td><a href='#5.5.4'>5.5.4</td><td></td><td></td><td><a href='#5.8'>5.8</td></tr>
|
||
<tr><td><samp>Undefined symbol "name", evaluated to 0</samp></td><td></td><td></td><td></td><td></td><td><a href='#5.7'>5.7</td><td><a href='#5.8'>5.8</td></tr>
|
||
<tr><td><samp>Unknown #directive "pseudo-directive"</samp></td><td></td><td><a href='#5.4.4'>5.4.4</td><td><a href='#5.5.4'>5.5.4</td><td></td><td></td><td><a href='#5.8'>5.8</td></tr>
|
||
<tr><td><samp>Unknown argument "name"</samp></td><td></td><td></td><td><a href='#5.5.3'>5.5.3</td></tr>
|
||
<tr><td><samp>Unterminated character constant 't understand.</samp></td><td></td><td><a href='#5.4.1'>5.4.1</td></tr>
|
||
<tr><td><samp>Unterminated expression</samp></td><td></td><td><a href='#5.4.5'>5.4.5</td></tr>
|
||
<tr><td><samp>Unterminated header name <header.h</samp></td><td></td><td><a href='#5.4.1'>5.4.1</td></tr>
|
||
<tr><td><samp>Unterminated macro call "macro( a, (b,c)"</samp></td><td></td><td><a href='#5.4.9'>5.4.9</td></tr>
|
||
<tr><td><samp>Unterminated string literal</samp></td><td></td><td><a href='#5.4.1'>5.4.1</td></tr>
|
||
<tr><td><samp>Unterminated string literal, catenated to the next line</samp></td><td></td><td></td><td><a href='#5.5.1'>5.5.1</td></tr>
|
||
<tr><td><samp>Variable argument macro is defined</samp></td><td></td><td></td><td></td><td><a href='#5.6'>5.6</td></tr>
|
||
<tr><td><samp>Wide character constant L'abc' is out of range of unsigned long</samp></td><td></td><td></td><td><a href='#5.5.4'>5.5.4</td><td><a href='#5.6'>5.6</td><td></td><td><a href='#5.8'>5.8</td></tr>
|
||
<tr><td><samp>Wide character constant L'abc' is out of range</samp></td><td></td><td><a href='#5.4.6'>5.4.6</td><td></td><td></td><td></td><td><a href='#5.8'>5.8</td></tr>
|
||
</table><br>
|
||
<br>
|
||
|
||
<h1><a name="6" href="#toc.6">6. バグ報告等</a></h1>
|
||
|
||
<p>プリプロセスの Standard C 適合度を検証するための Validation Suite を <b>mcpp</b> のソースとともに公開しています。Standard C のプリプロセスのすべての規定を検証できるものにしたつもりです。もちろん、<b>mcpp</b> はこれを使ってチェックしてあります。それも多くの処理系でコンパイルしてチェックしてあります。したがって、バグや誤仕様はほとんどないつもりですが、しかし、まだいくつか残っている恐れは十分あります。</p>
|
||
<p>もし、不可解な動作が発見されたら、ぜひご報告ください。<br>
|
||
もし、
|
||
"Bug: ..." という診断メッセージが出たら、それは間違いなく <b>mcpp</b> または処理系の（たぶん <b>mcpp</b> の）バグです。また、たとえむちゃくちゃな「ソース」でも、それを食わせることで <b>mcpp</b> が暴走するなら、それもバグです。</p>
|
||
|
||
<p>バグ報告には次のようなデータを付けてくださるようお願いします。</p>
|
||
<ol>
|
||
<li><b>mcpp</b> を移植した処理系。<br>
|
||
<li>バグと思われるものを再現できるなるべく短いサンプルソース。
|
||
<br>
|
||
<li>その処理結果。
|
||
<br>
|
||
</ol>
|
||
|
||
<p>バグ報告のほかにも、<b>mcpp</b> の使い勝手、診断メッセージ、このドキュメントの書き方、などについてご意見をお寄せください。<br>
|
||
ご意見と情報は</p>
|
||
<p><a href="http://mcpp.sourceforge.net/"> http://mcpp.sourceforge.net/</a></p>
|
||
<p>の "Open Discussion Forum" またはメールでお願いします。
|
||
</p>
|
||
|
||
</body>
|
||
</html>
|