アカウント名:
パスワード:
GCCのマニュアルに、charはバイトアクセスしますと書いてない限り、バグとは言い難い気がするけど。
Because this is not aquestion of "the standard is ambiguous", this is a question of "thecompiler turned good code into code that could SIGSEGV in user space too,if 'malloc()' happened to return a pointer at the end of an allocation".
「legal optimization」って言いたくなるのも
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲを呼ぶ -- ある傍観者
「本物の」バイト単位でのメモリアクセスが必要だって事? (スコア:0)
Re:「本物の」バイト単位でのメモリアクセスが必要だって事? (スコア:5, 参考になる)
i386系はアライメントにあまりうるさくないからページ境界をまたがない限りは表面化しないけど
> char c = *p++;
このコードをワードアクセスなんかにされたら、ARM/MIPS/SHなどのアライメントに厳しいCPUじゃ、一発アウトですよね。
この調子だと文字列操作なんかで良く使う
> while ((c = *str++) != '\0')
見たいなコードも怪しくなってくるんで、「legal optimization」って言いたくなるのも良くわかるなぁ。
# gccの最適化に伴う弊害ではstrict aliasing関連もちょっとやりすぎな気がする
Re:「本物の」バイト単位でのメモリアクセスが必要だって事? (スコア:1, おもしろおかしい)
GCCのマニュアルに、charはバイトアクセスしますと書いてない限り、バグとは言い難い気がするけど。
Re:「本物の」バイト単位でのメモリアクセスが必要だって事? (スコア:1, すばらしい洞察)
C言語なんだから(w
言ってること分かるか?
Re:「本物の」バイト単位でのメモリアクセスが必要だって事? (スコア:0)
言えないわけで、「壊れるところに変数が割り当たってない」前提のもとでは
「バグ(C言語の仕様違反)とは言えない」という元コメントの指摘は正当なものだと思います。
もちろん、Linusはバグだと主張するために、malloc() の実装によっては、
この前提条件が成り立たない場合がありうることを指摘しています。
Re:「本物の」バイト単位でのメモリアクセスが必要だって事? (スコア:0)
必死だな(w
Re:「本物の」バイト単位でのメモリアクセスが必要だって事? (スコア:0)
それだけでCの仕様に違反していると言えないのは事実。
元コメントはそこまで考えてないようにも読めるけど。
Re:「本物の」バイト単位でのメモリアクセスが必要だって事? (スコア:0)
Re:「本物の」バイト単位でのメモリアクセスが必要だって事? (スコア:1)
Re:「本物の」バイト単位でのメモリアクセスが必要だって事? (スコア:0)
確かに言ってるのは「legal optimization」だし。
Re:「本物の」バイト単位でのメモリアクセスが必要だって事? (スコア:0)