http://www.gotw.ca/publications/c_family_interview.htm

Ritchie: I added some things under some pressure from users that I don't think were done well.
(snip)
The "static" keyword is very strange, expressing both a storage lifetime and what the standard calls "linkage" (external visibility).

ユーザーの圧力が原因だそうで…。

> そういえばファイルスコープって、Cソースとオブジェクトファイル、どちらの"ファイル"なんだろう？
インタビューの通り linkage 単位ですね。
Cソース単位にならない例として、
include されるファイルで static な変数を定義して include する側で参照したりできます。

そうも言ってられない例として。
うちの環境(ubuntu)だと、↓のコードのコンパイルが通りません。

#define __s 0
#include<stdio.h>
int main() { printf("Hello, world!\n"); }

理由は stdio.h 内のプロトタイプ宣言の引数名に __s が使われてるから。
なんで stdio.h が __s なんて名前を使っているかというと、__s が予約されてるから。

#define s 0

なら通る。
言語仕様上通さなきゃならない。
だから stdio.h 内のプロトタイプ宣言の引数名に s が使われることはない。

「予約済み」がどういう意味なのかは理解しておくべき。

一応 Common Criteria というセキュリティの国際規格があります。
資料がIPAから公開されています。 http://www.ipa.go.jp/security/jisec/cc/
真面目に分類しようとすると「セキュリティとは何ぞや」という話からしなければならず、
とてもめんどくさいことになります。

他には microsoft の「悪用可能性指標」「セキュリティ情報の深刻度評価システム」あたりがあります。
https://technet.microsoft.com/ja-jp/security/cc998259.aspx
https://technet.microsoft.com/ja-jp/security/gg309177.aspx
ヤバさはわかりやすいですが、具体的に何がどうなるのかわかりにくくなります。

オープン・クローズ戦略は「発明を公開するかしないか、するならどう公開するか」という戦略の事ですね。

例えば発明が「音声情報を記憶できる設計図」みたいなものだった場合、
普通特許は取りません。
他社が特許を侵害しても、設計図が公開されなかったら侵害を発見できません。
技術が流出するだけ損です。

しかし、設計プロセスを標準化して
「国に提出するソフトウェアには音声情報を記憶した設計図が無ければならない」
みたいな決まりを作ることができそうなら、
特許を取っておく戦略もありえます。
# 標準に回避不能の特許をねじこむと大変儲かります

また、既に「紙に音声情報を記憶する装置」の特許を持っているなら
「音声情報を記憶できる設計図」を無償で公開しつつ
装置の方で儲ける戦略もあるでしょう。

発明をオープンにするかクローズしておくかで色々な選択肢があるわけです。

ところで(特許申請前の)発明が個人のものであるなら、
それを特許申請するか否かを会社が決めていいのか？という疑問が出てきます。
国外企業はこれを理由に日本に研究所を置くのを避けるかもしれません。
「職務の発明は会社のもの」ということにしておけば、
まあ、とりあえずは、この辺の問題はなくなります。

元ACとは別人ですが。

6.3.2.3 Pointers の 7 に

A pointer to an object or incomplete type may be converted to a pointer to a different
object or incomplete type. If the resulting pointer is not correctly aligned57) for the
pointed-to type, the behavior is undefined.

とありますので、 char * を uint64_t * に変換した時点で C99 的には undefined だと思います。
何が correctly aligned かは規格書中では述べられていない(と思う)ので
コンパイラのバグかどうかはちょっとわかりませんが…。

あと、 -O3 に -ftree-vectorize が含まれているので SIMD の使用は明示されてしまっていると思います。

今時大学とかにwikiがあったりするので、
ロートルかどうかは関係ないんじゃないですか？
どちらかというとwikiを使う人か否かの差では。

私: Why don't you run on iPhone 4?
Siri: I can't answer that. But I could search the web for it, if you like.

私: Do you know iPhone 4?
Siri: Everything you need to know about Apple products is at Apple's web site:

硬く口止めされているようです。

本当ですね。勉強になりました。
この文章の意味をずっと勘違いしてました…。

これが未定義の挙動になる理由は "6.5.16.1 Simple Assignment" の
> If the value being stored in an object is read from (中略) the behavior is undefined.
の方じゃないでしょうか。

いえ、不具合の修正方法の話でも言語仕様の拡張の話でもなく
「元AC(#1972743)で述べられているスタック操作がおかしい」
という話をしたつもりでした。
つまりコンパイラの実装方法の話です。

「スタックポインタの下は揮発性」という環境下で
「addressee がスタックポインタの下を指すポインタを返す」というコードを吐くコンパイラは
間違ってるのではないかと思います。