プログラムが (exit() によって) 異常終了した場合、エラー コードを返します。標準的な状況では、基礎となる errno を返すだけです (たとえば、失敗した malloc の ENOMEM など)。ただし、システムエラー番号が定義されていない自分の理由で終了しなければならない場合もあります。
既存のエラー値と競合しないようにするには、どのエラー値を返す必要がありますか。それとも、私はすべてのことを逆さまにやっていますか？
編集：質問がわかりにくかったら申し訳ありません。enum などについては話していません (エラー コードを定義するためのメカニズムです)。標準的な値と衝突せずに取り込める値の範囲について話していました。
私が知らなかったのは、プログラムが 8 ビットのステータスしか返せないということでした。したがって、@r は正しいようです。これは、私のカスタム エラーは言うまでもなく、すべての標準的なエラーに対応するには少し小さすぎます。だから1/0です:)
通常、戻りコードの幅は非常に小さく、たとえば 8 ビットに制限されているため、多くの情報を格納するのは困難です。プログラムがシェルスクリプトで使用することを意図していない限り、0/1 (成功/失敗) 以外の終了コードを気にすることはありません。その場合、潜在的なシェルスクリプトがチェックする必要があるエラーケースを把握する必要があるだけです。それらを区別します（たとえば、「一致なし」と「検索中にリソースが使い果たされた」）。
既存のエラー値と競合しないようにするには、どのエラー値を返す必要がありますか。それとも、私はすべてのことを逆さまにやっていますか？
複雑にしないでおく。エラー コードの最も重要なテスト (単純な関数にも有効) は、呼び出し元がそれに対して何ができるかです。私は、人々がすべてのユニークなケースに対して数百/数千のエラーコードを導入し、最終的にエラー処理が完全に混乱するプロジェクトを見てきました(彼らはすべての関数/SQLステートメントに固有の終了コードを与えようとしていました)。そしてそれ - エラー処理 - はまさに終了コードに関係する当事者です。
リターン コードに関する私の個人的なルールは、それらがエラー処理に役立つことを確認することです。たとえば、バッチ プログラムの場合、次のようなステータス コードを確認できます。
これは、呼び出し先ではなく、呼び出し元の POV からエラー コードを考慮する必要があることを強調するための単なる例です。たとえば、完全/部分的な自動化が対象ではなく、ユーザーがログ ファイルを分析する必要がある場合は、0 または 1 を返すだけで十分です。
それを行うにはいくつかの方法があります。
1）列挙型-これは次の方法で実行できます。必要に応じてさまざまなエラーコードを追加し、それらをグループに入れる柔軟性があります。ユーザー認証、ファイルアクセス、APIエラーなどに関連するエラーを言います。
enum
{
ERROR_GROUP_1 =100,// This gives 99 error codes for a particular group, can be initialised to negative value too.
GROUP1_1,
.
.
ERROR_GROUP_2 = 200
GROUP2_2,
.
.
and so on
};
2）プリプロセッサディレクティブを使用する
#define ERROR_CODE_START 00000000L
#define ERROR_CODE_1 (ERROR_CODE_START + 1)
3）intとしての負の戻り値ですが、参照が値について十分に文書化されている必要があるため、これは多くの苦痛になります。
4）GErrorのような構造を作成できます。すべてのAPIでこの構造への参照を渡し、これに入力します。NULLでない場合、呼び出し元はAPIに設定されるエラーコードと文字列を確認できます。
Posix準拠のシステムでは、0〜255の範囲外の数値を返す意味はまったくありません。これは、wait（）システムコールでは、プログラムの戻り値の下位8ビット（または16ビット）しか取得できないためです。ビット）。
実際には、おそらく0と1だけのほんの一握りのコードが必要です。詳細情報は、stderrを介して、より便利な（人間にとって）テキスト形式で伝達できます。
enumを使用してエラー コードを定義することを検討しましたか?
とにかく、ここに興味深い議論があります。