Sunday, September 20, 2009

gcc.gnu.org/bugs.html


http://gcc.gnu.org/bugs.html


Reporting Bugs バグの報告

The main purpose of a bug report is to enable us to fix the bug. The most important prerequisite for this is that the report must be complete and self-contained.

バグレポートの目的は、バグの修正が可能である事です。一番重要なのは来れのための前提条件が、完全で必要なものが全て揃っている(self-contained)ということです。

Before you report a bug, please check the list of well-known bugs and, if possible, try a current development snapshot. If you want to report a bug with versions of GCC before 3.4 we strongly recommend upgrading to the current release first.

バグを報告する前に、既知のバグリストをチェックしてください。可能なら、現状での開発状況も確認してください。もし、GCC V3.4以前のバグについて報告したいなら、最初に最新版にバージョンアップすることを強くおすすめします。

Before reporting that GCC compiles your code incorrectly, please compile it with gcc -Wall and see whether this shows anything wrong with your code that could be the cause instead of a bug in GCC.

GCCがあなたのコードを誤ってコンパイルすることを報告する前に、gcc -Wallでコンパイルすると共にこれがあなたのコードでGCCのバグの代わりに原因となっている何かおかしなものを出していないか確認してください。

Summarized bug reporting instructions バグレポートの方法(概要)

After this summary, you'll find detailed bug reporting instructions, that explain how to obtain some of the information requested in this summary.

この概要の後に、あなたは、詳細なバグレポートに指示を見つけて、それによってこの概要で要求された何らかの情報を得る方法がわかります。

What we need われわれが求めていること

Please include in your bug report all of the following items, the first three of which can be obtained from the output of gcc -v:

* the exact version of GCC;
* the system type;
* the options given when GCC was configured/built;
* the complete command line that triggers the bug;
* the compiler output (error messages, warnings, etc.); and
* the preprocessed file (*.i*) that triggers the bug, generated by adding
-save-temps to the complete compilation command, or, in the case of a bug report for the GNAT front end, a complete set of source files (see below).

バグレポートには、以下の項目を全て含めてください。最初の3つは、gcc -vの出力から得られます。

  * GCCの正確なバージョン。
  * システムタイプ。
  * GCCが構成されたか、またはビルドされたときのオプション。
  * バグの引き金となる完全なコマンドライン。
  * コンパイラの出力(エラーメッセージ、ワーニング)
* バグを引き起こした前処理されたファイル(*.i) または、
   完全なコマンドに -save-tempsを追加したことにより生成されたもの、または
   GNATのフロントエンドのバグレポートの場合には、完全なソースファイル
   (以下を参照)

   

Tuesday, September 8, 2009

guarante to work 動作することを保障する

The Windows Vista Hardware Compatibility List (HCL) is a list of hardware devices that have successfully passed the Hardware Compatibility Tests. All hardware on the HCL works with Windows Vista. Hardware not included on the HCL is not guaranteed to work successfully with Windows Vista.

Windows Vista ハードウェア互換性リスト (HCL) は、ハードウェア互換性テストに合格したハードウェア デバイスの一覧です。 HCL に記載されているハードウェアは、すべて Windows Vista で動作します。 HCL に記載されていないハードウェアについては、Windows Vista での動作は保証されません

Monday, September 7, 2009

System Requirements 動作環境

* System Requirements 動作環境/動作条件/システム用件

関連する単語/フレーズ
- Supported Operating Systems (対応のOS)
- Supported Development Environments (対応の開発環境)

http://developer.android.com/sdk/1.5_r1/requirements.html

Environment Variable(s) 環境変数

This article describes how you can manage the environment variables in Windows XP. Environment variables are strings that contain information about the environment for the system, and the currently logged on user.

この資料では、Windows XP で環境変数を管理するための手順を説明します。環境変数は、システム環境や現在ログオンしているユーザーの情報を格納する文字列です。

You must be an administrator to modify a system environment variable. System environment variables are defined by Windows and apply to all computer users.

システム環境変数を変更するには、管理者である必要があります。システム環境変数は Windows によって定義され、そのコンピュータのすべてのユーザーに適用されます。

出展:
How To Manage Environment Variables in Windows XP

variables 変数

All variables shall be initialized before use.
全ての変数は、使用前に初期化すること。

The names of all global variables shall begin with the letter 'g'. For example, g_zero_offset.
全てのグローバル変数は、gから始めること。例: g_zero_offset.

bug (2) 再現性のあるバグ / reproducible bug

再現性のある(再現可能な)バグ / reproducible bug
再現できないバグ /non-reproducible bugs

例:
Safariのユーザインタフェースの再現可能なバグ /Reproducible Bug in UI on Safari

cf.
バグ報告書 (バグレポート) / bug report
バグとり / Bug-killing

bug (1) バグを発見する / detect bugs

It is always desirable to detect possible typos and as many other bugs as possible at compile-time; run-time discovery may be dangerous to the user of the product and require significant effort to locate.

コンパイル時にできる限り多くの入力ミスやバグを発見することが望ましい。実行時にバグを見つけることは、機器の利用者を危険にさらす危険性があるし、発見に大変な労力を要する。

出展:
 More bug-killing standards for firmware coding
 Embedded.com