2: 2008-09-08 (月) 15:28:00  |
3: 2009-11-17 (火) 12:08:05 |
| | -.bssセクションというのはそういう性質のものなのに、gccの最新版はデフォルトではひどいことをする。というのは、.dataセクション内の変数うちで初期値がゼロのものを.bssに割り付けようとするのである。.bssは本来ゼロクリアすることを保証してはいないのにだ。 | | -.bssセクションというのはそういう性質のものなのに、gccの最新版はデフォルトではひどいことをする。というのは、.dataセクション内の変数うちで初期値がゼロのものを.bssに割り付けようとするのである。.bssは本来ゼロクリアすることを保証してはいないのにだ。 |
| | -ただしこれにはもちろん理由がある。実はLinuxにしてもWindowsにしても、.bssがゼロクリアされることを保証しているのだ（MS-DOSは保証してない）。だからgccのこの方針は実害がないばかりか、.dataのセクションバイナリイメージが小さくなり、実行ファイルが小さくなる、アプリケーションのロードが速くなるというメリットがある。 | | -ただしこれにはもちろん理由がある。実はLinuxにしてもWindowsにしても、.bssがゼロクリアされることを保証しているのだ（MS-DOSは保証してない）。だからgccのこの方針は実害がないばかりか、.dataのセクションバイナリイメージが小さくなり、実行ファイルが小さくなる、アプリケーションのロードが速くなるというメリットがある。 |
| - | -しかしOSASKではそんなことは保証してない。OSASK-HBでも保証してない。「はりぼてOS」でも保証してない。そもそもそんなことを保証する必要がどこにあるのか。セクション本来の意味としては、ゴミデータで埋まっていていいと言っているのになんで数千、数万クロックを費やしてゼロクリアするのか。そのままでいいじゃないか。OSASKやOSASK-HB、そして「はりぼてOS」でさえもtek圧縮をサポートしているので、.data内のゼロの塊やゼロ以外の一定値の連続は数バイトに圧縮されてしまうので、アプリのサイズやロード時間は負けない。 | + | -しかしOSASKではそんなことは保証してない。OSASK-HBでも保証してない。「はりぼてOS」でも保証してない。そもそもそんなことを保証する必要がどこにあるのか。セクション本来の意味としては、ゴミデータで埋まっていていいと言っているのになんで数千、数万クロック（.bss領域の大きさによってはこれをはるかに超える）を費やしてゼロクリアするのか。そのままでいいじゃないか。OSASKやOSASK-HB、そして「はりぼてOS」でさえもtek圧縮をサポートしているので、.data内のゼロの塊やゼロ以外の一定値の連続は数バイトに圧縮されてしまうので、アプリのサイズやロード時間では負けない。むしろ格段に有利だ。 |
| | -実はLinuxやWindowsが本来初期化する必要のないはずの.bssをゼロクリアするようになったのには、ちゃんとした理由がある。それは、セキュリティのためだ。たとえばパスワードなどを管理するアプリが走って終了したとしよう。そうするとそのアプリが使ったメモリにはパスワードの残骸が残っているだろう。このメモリをそのまま他のアプリの.bssとして割り当ててしまったら、そしてそのアプリがいきなり自分の.bss領域を覗き込むようなアプリだったら、パスワードが見えてしまうかもしれないわけだ。これはまずい。こういうことが起こらないようにするために、LinuxやWindowsでは.bssはゼロクリアするという方針を決めたということだ。 | | -実はLinuxやWindowsが本来初期化する必要のないはずの.bssをゼロクリアするようになったのには、ちゃんとした理由がある。それは、セキュリティのためだ。たとえばパスワードなどを管理するアプリが走って終了したとしよう。そうするとそのアプリが使ったメモリにはパスワードの残骸が残っているだろう。このメモリをそのまま他のアプリの.bssとして割り当ててしまったら、そしてそのアプリがいきなり自分の.bss領域を覗き込むようなアプリだったら、パスワードが見えてしまうかもしれないわけだ。これはまずい。こういうことが起こらないようにするために、LinuxやWindowsでは.bssはゼロクリアするという方針を決めたということだ。 |
| | *** (2) | | *** (2) |
