jikkenjo.netjikkenjo.net適当なことを書くか書かないかわからないメモ帳。メニューコンテンツへスキップC言語のNOT演算(チルダ~)でよくわからない現象5件の返信H8マイコン用のプログラムとして、ビット演算をしているときに見つけました。環境は、windowsの上でcygwinを動かしていて、コンパイラはgcc4.3.4(20090894)とかいうやつです。typeなんとなく、NOTされたときに8ビット目(上位の範囲を超えた)が立っちゃってるんじゃないの的なことを匂わせます。c);}まぁ、こうやれば警告も出ません。なんとなく気持ちが悪いのですが、調べる気力もなかったので誰か理由を教えてください。15:18)コメントで答えが出ているのでそちらを参照。未割り当てのローカル変数が使用されました。03:31一般的な処理系では16進リテラルはintとして評価されてて、それをchar変数に代入しようとしてるからですねー。動的な評価を伴う代入文の場合は自動的な型変換チェックが無理なので(責任を持つと表明する意味で)明示的キャストが必要となる...というかんじでしょうか。mrxpthさん前半が答えですが、どちらかというと後半に興味をそそられました。16進リテラルがintとして評価され、かつ右辺が静的に評価されるパターン。0x70;では警告が出ませんでした。これはどう説明が付くのでしょうか。見てくださっていれば教えてください。04:020x70(より正確には0x00000070)はcharのビット的な意味での最大値(0xff)以下なので、暗黙の型変換によってcharに代入してもオーバーフローが生じないことが*コンパイル時に*わかってしまうので、安全な型変換と見なされ、警告は出ないわけです。オーバーフローが生じる代入がどう安全じゃないかまではたぶん言う必要ないと思います。0xffを越えるリテラルを代入しようとすればコンパイル時にcharの範囲を越えてることがわかるので、先ほどのように警告が出ます。01111111というわけですね。~0x80;というお馴染みの操作においてなぜ警告が出ないのかはっきりわかりました。ありがとうございました。04:27そうですね、その通りです。charな変数に入れてしまうことですね。~hoge;この文は完全に安全なものであり警告は出ず、hogeを名前つき定数として適切に命名すれば見通しも向上します。(#defineによる名前つき定数に対して型安全性やスコープや最適化などの点でメリットがあります)ついでに、今さらだけど、CではなくC++の場合、一応こういうコードでリテラルがint扱いになることを確認しました。http://ideone.com/z1w8Lコメントを残すメールアドレスが公開されることはありません。コメントデータの処理方法の詳細はこちらをご覧ください。WordPress%d人のブロガーが「いいね」をつけました。