>>518
基本的なことを理解していないようなので補足説明しますよ

まず関数内のローカル変数をスタック上に置く言語と全てヒープ上に置く言語の2種類に分かれます
このうち必ずヒープ上に置く言語でガベージコレクションを行なう言語は今回の問題が起きないので
ここでの説明では関数内のローカル変数をスタック上に置く言語を対象とします

スタック上に置かれたローカル変数の参照(ポインタ)を用いて関数内で様々な処理をしてももちろん大丈夫です
さらに別の関数を呼び出して先ほどのローカル変数の参照(ポインタ)を渡して別の関数で処理するのも問題ありませんし孫関数でも曾孫でも大丈夫です
そしてそれらの関数引き渡しの時に他の構造体変数に格納されて引き渡されることもあるでしようがそれでも大丈夫です
つまり他の複合的なデータ(配列や構造体など)に参照(ポインタ)が組み込まれて受け渡されることもありますが子孫の呼び出し関数にいるときは大丈夫です

問題が発生するのはその関数内ローカル変数を含む関数を終えたときです
ローカル変数の参照(ポインタ)が単体もしくは他の複合的なデータに格納されたまま呼び出し上位の関数に戻ってしまった時に問題が発生します
もちろん御存知のようにスタック上にローカル変数を確保した言語の話ですから関数を終えたときにスタックは開放されて参照(ポインタ)は無効となっています

この問題はCGの有無とは関係なくスタック上にも変数を確保する言語の場合は生じ得ます
さらにヒープ上に確保した場合でも非CG言語では生じ得ます
そして強力な型チェックを行なっていてもそれだけでは回避できない点にこの問題の難しさがあります
唯一の解決方法は言語が各変数(領域)のライフタイムを管理して更にその参照が渡って行く先々のライフタイムがそれより短いことを言語が保証することによります