話の本筋とはあまり関係しないのですが、補足です。
> > Null pointer, isn't it? It, however, is not necessarily zero (0) by definition.
> K&Rさんの英文は「ヌルポインタは0と定義されている」というようなことが書かれています。
僕は「ヌルポは(必ずしも)ゼロでなくでもよさげじゃない?」みたいに解釈しました。
それで調査してみると、C言語ではそういうことになっているようです。
(つまり「(必ずしも)ゼロでなくでもよさげ」なわけです。)
実際に NULL != 0 な処理系に出会ったことはありませんが、その辺は主としてハードウェアの都合に左右されるようです。
以上は、C言語に関する話です。ABではどうなっているのでしょうか。
> ヌルポインタ (null pointer)と呼びます。(ABにもNULLという定数がありますよね)
その NULL ですが、実は api_system.sbp 内で定義されています。
このことから Win32 API に対応するために必要で定義されたものであり、従来の(C言語の)ヌルポとしての意味は強くないと考えています。
単に NULL = 0 という定数が存在すれば問題ないのでしょう。(蛇足:TRUE, FALSE もこのファイルで定義されています。)
ただし「解放した事を明示的にするために 0 を代入」することは立派なC言語の慣習ですので、これに倣うことは悪くないと思います。
解放したメモリに0を代入
> > 僕は「ヌルポは(必ずしも)ゼロでなくでもよさげじゃない?」みたいに解釈しました。
> たしかにそうですね。すいません。(英語力の無さがばれる……)
>
> > 以上は、C言語に関する話です。ABではどうなっているのでしょうか。
> ABのヌルポインタに関する規定は勿論わかりませんが、おそらく何も無いと思います。
> けれどWindowsでは0がヌルポインタですから、今のところ特に問題は無いといったところです。
> Cではコンパイル後がどうであれ、ソースコード上では常に0をヌルポインタとすることになっていますよね。
NULL(ヌル/ナル)とは元々の意味は「0」とか「無い」とか「無効」という意味
です。
http://dic.yahoo.co.jp/bin/dsearch?inde ... &pagenum=1
http://dic.yahoo.co.jp/bin/dsearch?p=nu ... &dname=1ss
で、初期化されていないメモリ領域に書き込むことは危険なので絶対にしては
いけません。
(強制終了することが多く、しない場合もありますがその場合は余計に危険)
ポインタ変数自体に数値を代入するのは結果的に指し示しているポインタ先を
書き換えているだけなのでOKです。
# ポインタ変数はポインタ変数用のメモリ領域が別に確保されています。
# なので、ポインタ変数(メモリ領域)へのポインタというのもあります。
メモリを動的確保した場合にmalloc()などが返すのは確保したメモリ領域の
ポインタで、このポインタは結局はただの数値に過ぎません。
(型は違いますが)
なので、この数値をポインタ変数に代入することでそのポインタ先を参照する
ことができるわけです。
# malloc()が&H12345678という数値を返してきた場合は&H12345678がその
# メモリ領域の先頭アドレスです。
# 0を代入した場合は指し示しているポインタが0なだけです。
あと、動的確保したメモリ領域がある場合、それを解放する際にアドレスが
必要になるので解放する前に書き換えることはしない方がいいです。
(その場合は別の変数にアドレスを一時的に退避させるとか...)
って、余計に分かりづらくなったかも。
> たしかにそうですね。すいません。(英語力の無さがばれる……)
>
> > 以上は、C言語に関する話です。ABではどうなっているのでしょうか。
> ABのヌルポインタに関する規定は勿論わかりませんが、おそらく何も無いと思います。
> けれどWindowsでは0がヌルポインタですから、今のところ特に問題は無いといったところです。
> Cではコンパイル後がどうであれ、ソースコード上では常に0をヌルポインタとすることになっていますよね。
NULL(ヌル/ナル)とは元々の意味は「0」とか「無い」とか「無効」という意味
です。
http://dic.yahoo.co.jp/bin/dsearch?inde ... &pagenum=1
http://dic.yahoo.co.jp/bin/dsearch?p=nu ... &dname=1ss
で、初期化されていないメモリ領域に書き込むことは危険なので絶対にしては
いけません。
(強制終了することが多く、しない場合もありますがその場合は余計に危険)
ポインタ変数自体に数値を代入するのは結果的に指し示しているポインタ先を
書き換えているだけなのでOKです。
# ポインタ変数はポインタ変数用のメモリ領域が別に確保されています。
# なので、ポインタ変数(メモリ領域)へのポインタというのもあります。
メモリを動的確保した場合にmalloc()などが返すのは確保したメモリ領域の
ポインタで、このポインタは結局はただの数値に過ぎません。
(型は違いますが)
なので、この数値をポインタ変数に代入することでそのポインタ先を参照する
ことができるわけです。
# malloc()が&H12345678という数値を返してきた場合は&H12345678がその
# メモリ領域の先頭アドレスです。
# 0を代入した場合は指し示しているポインタが0なだけです。
あと、動的確保したメモリ領域がある場合、それを解放する際にアドレスが
必要になるので解放する前に書き換えることはしない方がいいです。
(その場合は別の変数にアドレスを一時的に退避させるとか...)
って、余計に分かりづらくなったかも。
Re: 0を代入したい理由は?
> 私が推測する限り、ポインタに0を代入する理由を探したところ、
> 解放した事を明示するためという結論しか出なかったのですが、
> それでよろしいのでしょうか。
そういう理由なら、別に0を代入する必要は無いのでは?
一般論として、0を代入する理由があるにはあるけど、それは、
・情報漏洩防止。
つまり、メモリーを開放すると、他プログラムがらアクセスできるわけで、他プログラムが
スパイウェアだったら???
したがって、ポインタに0を代入するのではなくて、データにゼロを代入しないとやる意味がないし、
ゼロを代入してから開放であって、開放してからゼロを入れるのはOSによりブロックされる
(ブロックされないような組みかたが可能としても、ウィルスワクチンのような特殊な場合以外避けるべき)
のでは?
> 解放した事を明示するためという結論しか出なかったのですが、
> それでよろしいのでしょうか。
そういう理由なら、別に0を代入する必要は無いのでは?
一般論として、0を代入する理由があるにはあるけど、それは、
・情報漏洩防止。
つまり、メモリーを開放すると、他プログラムがらアクセスできるわけで、他プログラムが
スパイウェアだったら???
したがって、ポインタに0を代入するのではなくて、データにゼロを代入しないとやる意味がないし、
ゼロを代入してから開放であって、開放してからゼロを入れるのはOSによりブロックされる
(ブロックされないような組みかたが可能としても、ウィルスワクチンのような特殊な場合以外避けるべき)
のでは?
レスが一人歩きしてる気がしますが・・・
人により考えは違いますが、バグを減らす有効な手段だと思います。そういう理由なら、別に0を代入する必要は無いのでは?
なるほど、情報漏洩防止ですか。確かに、そのようなこともありそうですね。一般論として、0を代入する理由があるにはあるけど、それは、
・情報漏洩防止。