C言語の引数

RL78
CS+ forCC
でソフトを作っています。
例えば、関数 void xxfunc(uint32_t, uint32_t) があったとします。

メインで、
  uint16_t  aa;
  uint16_t  bb;
 
  aa = 1000;
  bb = 6000;
 xxfunc(aa, bb);
でコンパイルします。

引数の型が合わないのでワーニングが出ると思いましたが出ませんでいた。
暗黙の型変換だと思います。
このような場合でもワーニングを出すことはできますか?

Parents
  • ega258さん
    インフォメーション・メッセージ出力を有効にするをはいにすると
    :M0523034:Conversion in argument
    :M0523034:Conversion in argument
    が出ます、これではいけないですか。
  • ありがとうございます。
    cs+では確認できました。
    e2studioでもできるのでしょうか?
  • ega258さん、こんにちは。NoMaYです。

    CC-RLにその機能は無い筈です。CC-RLのコンパイラのヘルプを見直しても見当たらないです、、、CC-RXと話がごっちゃになっているのでしょうか?それとも私の見落としなのかな?

    IKUZO wrote:
    > インフォメーション・メッセージ出力を有効にするをはいにすると

    ega258 wrote:
    > cs+では確認できました。

  • NoMayさん、IKUZOさん
    すいません。
    私の確認値が違いでした。
    NoMayさんのご指摘通り、やはりできなかったです。
    そもそも、CS+でもe2STUDIOでもできないのでしょうか?
    型違いの代入などは、コンパイラ側で確認ができると思うのですが
    なぜできないのでしょうか?
Reply
  • NoMayさん、IKUZOさん
    すいません。
    私の確認値が違いでした。
    NoMayさんのご指摘通り、やはりできなかったです。
    そもそも、CS+でもe2STUDIOでもできないのでしょうか?
    型違いの代入などは、コンパイラ側で確認ができると思うのですが
    なぜできないのでしょうか?
Children
  • ega258さん
    私の使用したのはCS+ですが
    まず
    インフォメーション・メッセージ出力を有効にするをはいにすると
    インフォメーション・メッセージ出力にConversion in argumentが出力されるようになり
    警告レベルの設定項目で
    インフォメーション・メッセージ出力を警告にするという項目があり
    それを有効にすると
    警告はしましたよ、ただそれをすると非常に多くの警告がでますので
    わずらわしいと思いますが。
  • IKUZOさん、こんにちは。NoMaYです。

    その機能は、CC-RXにはありますが、CC-RL(とCC-RH)には無いのです。そして、CC-RXで検出されていても、今回は、RL78とCC-RLでのことなのです。この3種類のコンパイラは、必ずしも同一の仕様という訳ではなくて、C言語拡張仕様やコマンドラインオプションがそれなりにばらついています。そして、ワーニングレベルに関しては、CC-RXが最も高い設定が出来るような感じになってますね。

  • NoMaYさん
    CS+でもいろいろあってega258さんのはCC-RXでなくてCC-RLだったんですね
    気が付くのが遅かったですね、なるほど思い込みで回答してたみたいです
    CC-RXのコンパイラーはCC-RLよりも親切というわけなんでしょうか
    コンセプトの違いなんでしょうか、uint16_tをuint32_tに変換する等とは
    0x7FFFをuint32_tでは変わらず0xFFFFであれば0xFFFFFFFFとなって不安ではありますが
    理解していれば特に危険ではないように思いますが

    この私の理解で正しかったですかね?

  • CC-RX では可能らしいので、実際のプログラム作成は CC-RL を使用して行い、チェックのみ CC-RX で行うという運用は可能だと思います。
    CC-RL に依存した記述をしている箇所は条件コンパイル等で避ければ問題ないでしょう。
    お勧めいたしません。
  • IKUZOさん

    > 65534をuint32_tでは変わらず0xFFFFであれば0xFFFFFFFFとなって不安ではありますが

    私が勘違いしているのでなければ勘違いされてるような気がします。

     

    0xFFFFをuin32_tでキャストしても値は保持されるので、0xFFFFのままですね。

    (-1)をuin32_tでキャストしたときは0xFFFFFFFFになるので、これと勘違いされてるのかと。

    以下gccでの結果です。

    $ cat test3.c
    #include <stdio.h>
    #include <stdint.h> int main(void) { uint16_t u16_m1 = (uint16_t)-1; uint32_t u32_cast = u16_m1; uint32_t u32_m1 = (uint32_t)-1; printf("0x%x: 0x%x: 0x%x\n", u16_m1, u32_cast, u32_m1); } $ gcc test3.c $ ./a.out 0xffff: 0xffff: 0xffffffff $
     
  • IKUZOさん、

    > uint16_tをuint32_tに変換する等とは

    > 0x7FFFをuint32_tでは変わらず0xFFFFであれば0xFFFFFFFFとなって不安ではありますが

    uint16_t の値を uint32_t への変換では上位 16bit にゼロ拡張されるだけなので値に変化は生じません。

    Wandboxで実行

    符号ありの値をよりサイズの大きな符号なしの型に変換した場合には仰られてるような符号拡張が行われるため注意が必要となります。

    Wandboxで実行

  • imudakさんfujita nozomuさん
    符号付きと符号なしを混同していたようですゼロ拡張でしたね
  • IKUZOさん
    uint16_tで0xFFFFのデータをuint32_tにキャストすると、ちゃんと0x0000FFFFとなります。
    0xFFFFFFFFにはなりませんけど。

    私の例えがよくなかったです。
    例えば、足し算や引き算、掛け算、割り算で、
    uint8_tとint16_tを計算した場合、きちんとキャストしておかないと
    結果がおかしくなる場合があるのではと思っています。
    コンパイラーで型違いを指摘してくれれば、未然に防げるのかなと思った次第です。
  • ega258さん
    長年やっていると、いろいろありますよね、最近コンパイラーでは警告とか出してくれるので、それを注意するということでしょうか、でも「型の違うところに適当に合わせない」ということが無難な線ですよね
    別の話ですがprintfなんかで
    char b=50;
    printf("%02X",b);
    なんかですと値によってはFFFFとか4桁になったりするので
    printf("%02X",(int)b & 0xFF);とかいろいろわからないことがあるのですが
    やっぱりコンパイラーの警告のみに頼らず、いろいろな値で実際に動作させて確認することだと思います。
  • ega258さん

    > 例えば、足し算や引き算、掛け算、割り算で、
    > uint8_tとint16_tを計算した場合、きちんとキャストしておかないと
    > 結果がおかしくなる場合があるのではと思っています。
    > コンパイラーで型違いを指摘してくれれば、未然に防げるのかなと思った次第です。

    コンパイラやlintの設計者も同じことを考えていて、
    「きちんとキャストしておかないと結果がおかしくなる(可能性がある)場合」については、
    コンパイラやlintなどはきちんと警告を出します。

    引っかかっているのは、
    「値の保持が保証され警告を出す意味がないuint16_tからuint32_tへのキャスト」
    などについても警告を出して欲しい、という点です。

    そんなキャストにまで警告出しても冗長なだけなのでは、と皆さん色々な事例を出して
    説明しているのかと思います。