非 void C 関数で return ステートメントを省略すると機能する場合があるのはなぜですか (また、そうすべきではないのはなぜですか)?

C での Return ステートメントの省略

C では、void 以外の関数を return ステートメントで終了するのが通例です。ただし、Strawberry Perl とともに配布される g の特定の Windows バージョンで奇妙な現象が観察されています。このバージョンでは、void 以外の値を返す関数で return ステートメントを省略できるため、予期しない動作が発生します。

次のメンバー関数について考えてみましょう:

struct boundTag Box::getBound(int side) {
    struct boundTag retBoundTag;
    retBoundTag.box = this;
    switch (side)
    {
        // set retBoundTag.bound based on value of "side"
    }
}

この関数は、次のように設計されています。バインドされたタグを表す構造体を返します。ただし、開発者は誤って return ステートメントを省略しました:

// ... code from above
}

この関数をテストするとき、開発者は return ステートメントが欠落しているにもかかわらず、有効な出力を受け取りました。 return ステートメントを削除した後でも、コードは警告なしでコンパイルされます。

根本的な問題は、非 void 関数で return ステートメントを省略すると、未定義の動作が呼び出されるということです。 ISO C -98 標準では、void 以外の関数の末尾からのフローは値のない return と同等であり、その結果未定義の動作が発生すると明示的に規定されています。

// ... code from above
// Undefined behavior
}

このシナリオでは、g はおそらくコンパイラが意図した戻り値を判断できないため、ガベージ値が返されます。この戻り値をコード内で使用することは危険であり、予測できない結果につながる可能性があります。

デフォルトでは g は警告を発行しない場合がありますが、コンパイル中に -Wall オプションを使用すると、コンパイラはこれらの場合について警告を強制的に出します。このオプションは、欠落している return ステートメントを強調表示し、そのような未定義の動作を防ぐのに役立ちます。

したがって、戻り値がすぐに使用されない場合でも、void 以外の関数には常に return ステートメントを含めることが重要です。これにより、コードが C 標準に準拠し、潜在的な未定義の動作が回避されます。

以上が非 void C 関数で return ステートメントを省略すると機能する場合があるのはなぜですか (また、そうすべきではないのはなぜですか)?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。