#clang
マージソートプログラムのカバレッジを測定してみた
プログラムを作成すると試験を実施するが、全てのルートを試験できているのかどうかが懸念される。最近ではカバレッジツールも増えてきていて、フリーで使用できるものもある。
とはいうものの、C言語のカバレッジは実は少し難しい。CPUそれぞれのネイティブコードを作成するものだから、マシンコードが実行されたのかどうかを判定しなければならず、CPUに依存するところが多くあるためである。このような状況にあって、
【C言語】char が signed とは限らなかったという話 （C言語のおおらかな仕様に右往左往する日々）
発端こちらの記事でご指摘頂いたことが始まりでした。
ご指摘内容は、次のコードが無限ループになっているというもの。
char c;for (c = 1; c < 0x80; ++c)
char の範囲が
-128 ～ 127
であるとするならば、それは常に
0x80 = 128
よりも小さくなります。
このため、次の条件は必ず真であり、偽になることがありません。
c < 0x80
ただ、
【C言語】clang と VS と Eclipse と私（まだまだ続く 関数の評価順序）
C言語の関数の評価順序について。
こちらの記事の続きです。
しつこいわ、私って(笑)。
前記事で次のように申しました。
VS、gcc は本当に第3引数から評価しているのか
そして。
(1)引数の並びを逆にするとどうなるのか
(2)引数で関数を呼び出すとどうなるのか
この(1)(2)を試してみました。
(1)引数の並びを逆にするとどうなるのかソースコード
oe1、oe2、oe3、o
C言語コンパイラ依存した話の続編「clang はどうコンパイルするのか」
こちらの記事の延長戦です。
というわけで（どういうわけ？）、 clang コンパイラが吐き出したアセンブラを解析してみました。
結論から言うと、clang コンパイラの場合は次のようになります。
引数 i 、 j は三項演算する前に待避しておく。
「j--」（後置デクリメント）は、 j-- する前の値を別のレジスタに待避する。
まず、clang が出力したアセンブラを見てみます。スマホ版