投稿2018/08/28 13:54
C言語を独学で勉強しているものです。今回初めて質問させていただきます。
ポインタについて調べていると、strict aliasing rulesというものを発見し、オブジェクトのエイリアス（別名）になるための規則があることを初めて知りました。
その規則は、以下のものであることを学びました。（C99）
オブジェクトに格納された値に対するアクセスは，次のうちのいずれか1つの型を持つ左辺値によらなければならない。
メンバの中に上に列挙した型の1つを含む集成体型または共用体型（再帰的に包含されている部分集成体または含まれる共用体のメンバを含む）
0. 文字型
このうち、構造体・共用体の規則以外は理解できたのですが、４つ目の
"メンバの中に上に列挙した型の1つを含む集成体型または共用体型（再帰的に包含されている部分集成体または含まれる共用体のメンバを含む)"
がどのような意味を持つのか、そしてどのような形でそのケースのエイリアシングが実現されるのかが分からないです。
（ポインタのアライメントの未定義については今回は考慮せず、エイリアシングのみを焦点にしています。）
例えばコードが、
#include<stdio.h> #include<stdlib.h> typedef struct s { double a; float b; int c; short d; }st_alias; typedef union t { double e; float f; int g; short h; }uni_alias; int main(void){ st_alias * ali_s; uni_alias * ali_u; int test_1 = 10; short test_2 = 22; double test_3 = 123.4; float test_4 = 222.2f; system("pause"); return 0; }
のような状態であるとき、"ali_s"と"ali_u"のポインタは、変換におけるアラインメントが正しければ上記の規則によって、main関数内の４つのオブジェクトのエイリアスになることができ、ポインタを経由してアクセス（変更・読み取り）ができるということなのでしょうか？そして、それはメンバアクセス演算子（-> .)によって実現するのでしょうか？
ご教授して下さるととてもありがたいです。どうか宜しくお願いします。
visual studio 2017 C++ でポインタにオブジェクトのアドレスを代入して、それを経由したアクセスをしたのですが、期待した結果ではありませんでした。（アラインメントによるアドレスの変化はなかったことは確認済みで、それが原因ではないと思っています。）
また、visual studio C++ が strict aliasing rules をサポートしているのかについて調査をしてみたのですが、そのようなものは見つかりませんでした。
もしかしたらそもそもサポートしていないのではないのかと思いました。
（inline関数の外部結合の定義形式も、Ｃ99のものではなくC++の形式をサポートしている状況もあったため、そのようなこともあるのではないのかと…）
visual studio C++ 2017を利用しています。(.cの形式で使用しています。）
また、strict aliasing rulesの日本語形式のものは、
https://www.jpcert.or.jp/sc-rules/c-exp39-c.htmlから引用させていただきました。
回答3件
0
ベストアンサー
strict aliasing rulesというものを発見し、オブジェクトのエイリアス（別名）になるための規則があることを初めて知りました。
C言語仕様の"Strict Aliasing Rules"は、C言語プログラマのための規則ではなく、C言語コンパイラ製作者のための規則という側面が強いものです。
"Strict Aliasing Rules"の本題は、Cコンパイラは「変数型が異なる場合は、互いにエイリアス(別名)となっている可能性を排除して良く」、「エイリアス不在を前提とした生成コード最適化をして良い」というものです。"Strict(厳密な)"とは、コンパイラ視点からは「型に互換性がある場合は、互いにエイリアス(別名)の可能性を考慮すべき」、プログラマ視点からは「互換性のない型でエイリアスを作ってはいけない」というニュアンスから来ています。
オブジェクトに格納された値に対するアクセスは，次のうちのいずれか1つの型を持つ左辺値によらなければならない。
(略)
上記5つのルールは、"Strict Aliasing Rules"の例外事項を規定しています。例えば5番目「文字型(a character type)」は、基本ルールに従うとint型とchar型は互換性のない型なので互いにエイリアスであってはいけないが、例外規定により「エイリアスになり得ると考慮すべき（コンパイラ視点）」「エイリアスを作っても良い（プログラマ視点）」という意味です。
本題に入る前に、"Strict Aliasing Rules"の基本ルールを理解する必要があります。
c
1void f(int* a, double *b) { 2 // int型とdouble型は異なる型のため、int型(*a)への代入は... 3 *a = 0; 4 // double型(*b)変数のエイリアスとなっている可能性を考慮する必要がない。 5 *b = 3.14; 6 // つまり下記処理で改めてメモリ位置*aから値を読み込む必要はなく、 7 // 最適化によって "前掲処理で代入した直値0" をそのまま使って良い。 8 printf("%d", *a); 9 // コンパイラは↑をprintf("%d", 0);やprintf("0");に最適化しても良い。 10}
このうち、構造体・共用体の規則以外は理解できたのですが、４つ目の
"メンバの中に上に列挙した型の1つを含む集成体型または共用体型（再帰的に包含されている部分集成体または含まれる共用体のメンバを含む)"
がどのような意味を持つのか、そしてどのような形でそのケースのエイリアシングが実現されるのかが分からないです。
この例外規則の解釈は、下記の通りです。プログラマ視点では当然のことを言っているように見えるかもしれまん。
c
1// int型を含む集成体(struct)型は... 2struct S { 3 double b; 4 int i; 5}; 6 7void g(struct S* s, int* a) { 8 // int型と互換性のある型(＝int型自身を含む)のエイリアスになっている可能性があるため... 9 *a = 0; 10 // 下記の処理によりメモリ位置*aが書き換わる可能性がある 11 struct S t = { 3.14, 42 }; 12 *s = t; 13 // つまり下記処理では改めてメモリ位置*aから値を読み込まなければならない。 14 printf("%d", *a); 15}
visual studio C++ が strict aliasing rules をサポートしているのかについて調査をしてみたのですが、そのようなものは見つかりませんでした。
もしかしたらそもそもサポートしていないのではないのかと思いました。
コンパイラが"Strict Aliasing Rules"をサポートするとは、前掲のように「型情報に基づいた積極的コード生成最適化を行う」という意味です。最新のVisualC++事情までは把握していませんが、私が知る限りはVisual C++はこのような積極的な最適化を行いません。なお、GCCやClangは積極的な最適化をサポートします。
善意的に解釈すればプログラマに優しく、悪意を持って解釈すれば最適化性能が劣るコンパイラということになります。しかし、"Strict Aliasing Rules"を厳密に守っているプログラムはほとんど存在せず（たぶん）、積極的な最適化はしばしばトラブルの元になります。C言語仕様で規定する以上「Cコンパイラが正しくプログラムが誤っている」のですが、現実的には"Strict Aliasing Rules"に基づいた最適化を無効化して運用されることが多いようです。GCC、Clangでは-fno-strict-aliasingオプションが用いられます。
投稿2018/08/28 16:23
編集2018/08/29 02:54
総合スコア6191
0
こんにちは。
strict aliasing rules を知らなかったので、ググって見たらyohhoyさんの記事が出て来ました。
（翻訳）C/C++のStrict Aliasingを理解する または - どうして#$@##@^%コンパイラは僕がしたい事をさせてくれないの！
分かりやすいです。
要するに「変なことしたらコンパイラが最適化してしまって、コードをまるっと削除するかも知れないよ」ってことみたいです。（もっと他のことも起こるかも知れません。鼻から悪魔系です。）
「オブジェクトに格納された値に対するアクセスは，次のうちのいずれか1つの型を持つ左辺値によらなければならない。」は、このルールに従えば、その「変なこと」に該当しないということですね。
yohhoyさんの記事の「壊れたバージョン」のプログラムのuint16_t *ptr=(uint16_t*)&acopy;の*ptrはacopyと互換性がないため、ptrがacopyの一部をポイントしていないとコンパイラは仮定してよいわけです。（どうみてもポイントしてますが、ルール上それが許されることになります。）
ということは、ptrが指す先はどこかあらぬメモリとして解釈できるわけです。あらぬメモリへの操作は最適化によりまるっと削除しても「正しいプログラム」の動作には影響しないと判断して良いということです。だから、コンパイラは削除してもよいので、削除するコンパイラも存在するという流れです。
古いコンパイラでは再現しました。警告もでます。しかし、これより新しいものではことごとく再現せず、警告もでませんでした。削除しないコンパイラも少なくないということですね。
構造体については、構造体の中にある、int型等をint型ポインタは指すことができるので、その構造体とint型ポインタの指す先がエイリアス（同じ領域）かも知れないとコンパイラは仮定しなければならないということでしょう。
逆に云うと、short型を一切含まない構造体と、short型ポインタはエイリアスにならない（同じ領域ではない）とコンパイラは仮定して最適化して良いということです。
投稿2018/08/28 15:58
編集2018/08/28 16:00
総合スコア23272
0
のような状態であるとき、"ali_s"と"ali_u"のポインタは、変換におけるアラインメントが正しければ上記の規則によって、main関数内の４つのオブジェクトのエイリアスになることができ
アラインメントとか以前に何の関係もない赤の他人です。strict aliasing rules以前の問題。まずunionがなにか調べてください。
その構造体・unionに関してのstrict aliasing rulesってのは、私はC++規格書リーディング初心者なのであってるかわかりませんが、
（翻訳）C/C++のStrict Aliasingを理解する または - どうして#$@##@^%コンパイラは僕がしたい事をさせてくれないの！ - yohhoyの日記
アグリゲート（structまたはclass）もしくはunion型は、その内部に含む型のaliasとできます。（例：関数にintへのポインタが渡された場合、内部にintを含むstructやunionへのポインタ、もしくはintを含む別のstructやunionを含む型、もしくは...と際限なく、int*は別のポインタが指すstructやunionに含まれるintを指すことができます。）
を解釈するとおそらく次のようなことを指します。
cpp
1struct Hoge { 2 int fuga; 3}; 4int main() 5{ 6 Hoge hoge; 7 hoge.fuga = 2; 8}
というコードがあったとき、hogeはfugaのaliasだと思われます。これはよく考えればそうおかしいことではないです。なぜならば、構造体というのはつまるところポインタでアクセスしているからです。メンバーアクセスに使う演算子.は、多くの処理系では右辺の識別名からコンパイル時に構造体型変数のアドレス内でのオフセットを認識し、ポインタ演算でその要素にアクセスするコードを出力します(最適化は考えない)。
投稿2018/08/28 14:41
編集2018/08/28 14:51
総合スコア5852
あなたの回答
tips
プレビュー
Q&A
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2018/08/28 16:35
2018/08/29 01:27
2018/08/29 02:23 編集
2018/08/29 13:40
2018/08/29 13:50
2018/08/29 13:55
2018/08/29 14:02
2018/08/30 03:37 編集
2018/08/30 09:01
2018/08/30 09:09
2018/08/30 09:14
2018/08/30 09:15
2018/08/30 09:47 編集
2018/08/30 15:45
2018/08/31 08:00