構成プロパティ->全般->[プログラム全体の最適化]を「リンク時のコード生成を使用」から「プログラム全体の最適化なし」にすると直りました。
cl /O1 /GL test.cpp のように /O1 /O2 /Oxなどと GL(/LTCG) を組み合わせると発生して、 O1, O2単独やGL単独では発生しません。
VC 2008 SP1/CL 15.00.30729.01 for 80x86/LINK: 9.00.30729.01 x86版
includeヘッダは以下のとおり。
#include ＜windows.h＞
#include ＜stdio.h＞
#include ＜tchar.h＞
x86版バイナリが600K位なのに同じソースをIA64向けにコンパイルすると2M越えになってびびったのが懐かしいです。
2003年9月でした。
それから待てど暮らせど、一般に降りてこないし、Itaniumは速くならないし、.NET 1.1の64bit版もない。
そのうえでx86エミュレーションが遅いと。
その状況だと、.NET 1.1で書いたものをItaniumで走らすより、x86系CPUのほうが速いし安いということになりかねない。
(たぶん)その後、.NET2.0で64bitもできるようになったら、AMD64がでてきて安いし .NET1.1 32bit, .NET 2.0 32/64bit 全部普通の速度で走る。
WIN64ネイティブアプリは対応製品がない。64bitに対応したと思ったらAMD64版だけだったとかもありそう。
ItaniumはOracle専用マシンならHP-UXでいいきがするし、どっち向いてもWindowsの出番があんまりなさそう。
kb924449の MSのコンパイラが吐くコードがおかしい問題だって、話題にならなかったみたいだから、ほとんど誰も使ってないということでしょう。
こんな感じに情報だけ拾い続け、結局クロスコンパイルするだけで、私は実行することが一度もないまま消えていくのですね。
#ハイエンドサーバー系は完全に外野なので突っ込み歓迎
># これはがくっときてしまう人多そう…。
確かにIPAの存在も忘れてましたが、法人ではなくて個人を想像したコメントでした。
IPAがまとめてくれているので、個人でまとめる必要はないわけですね。
プログラミングガイドとかも、そういえばIPAでした。
脆弱性でデータ流出とかは話題になって(個人的には)記憶に残りやすいです。
一方「IPAが仕事しました」というのは、内容がおかしかったら話題になるけど、内容がまともすぎて、話題・記憶に残りにくいのかもしれません。
blogとかで紹介するときも、「IPAがまとめています→リンク。参考になります。」という感じで触れられるだけですから、
後で読もうと思ってリンクをたどらず、つい読み飛ばしてそのうち忘れます。
現場で、「IPAのこれ読んで」とか上に言われて渡されたりするのか、もしくは上の人は、渡したり確認したりしているんでしょうか。
#ここはひとつ、萌えキャラで擬人化してみんなに覚えてもらうというのはどうだろう。
携帯対応・変なファイヤーウォールを無視できるとして、今回の件では関係ないものもありますが、対策はこんな感じでしょうか。
専門家の方もxxはyyが悪いというばかりで、対策をまとめてくれないのでよくわからんのですよね。
ベーシック認証、クライアント証明は考慮外です。
step0: ログインIDとパスワードをURLに含めて持ち歩くのをやめる
step1: パスワード送信をPOSTにしてPOSTのみ受け付ける
step2: ログイン画面以外は、パスワードを利用せずにcookieを使う
step3: 全コンテンツでTLS・有効で信頼済みの認証局発行のサーバー証明書を使う
step4: cookieにはsecureフラグを立てる
step5: cookieには基本的にセッションIDのみを保存する
step6: セッションIDをjsessionidやphpsessionidなどでURIに含めない。受け付けない。(NG例:ぐぐる)
step7: セッションIDには推測されない一時的に生成されるIDのみを使う(NG例:JVN#07468800)
step8: ログイン前後でセッションIDを共有しない
step9: パスワードを変更したら、サーバー側で古いセッションIDを無効にする(NG例:twitterのidのっとり事件)
step10: パスワード再確認などを併用してセッションIDのサーバ側有効期間を短くする(例:yahoo)
step11: ログインIDとユーザーIDを分離する(例:mixi/ねとげ)
step12: ログイン追跡機能をつける(例:unixのlast login/yahooの履歴)
その他1: サーバー側のDBでのパスワード保存は、saltつきのハッシュ値などにする
その他2: CSSXSS/CSRF/XSS対策、正しいエスケープ処理をする
その他3: 簡単ログインを実装しない
その他4: メールでのパスワードリセット・確認はメールアドレスの生存期間を考慮した仕様にする(NG例:iTunes)
その他5: 脆弱性が公表されているバージョンのソフトウェアを使わない
>geocitiesやfc2とか無料webスペースを提供してるところは
geocitiesに関しては HTTP経由のファイルマネージャが使えます。
認証はhttps経由。yahoo共通のログインです。
http://geocities.yahoo.co.jp/filemanager
EXアップロードでアップもできます。ブラウザがあればFTPが使えなくても問題ありません。
今回の件に関するお知らせも1月13日付で出ています。
http://geocities.yahoo.co.jp/v/info/index.html
昔のgeoのFTPは、yahooとは別のパスワードだったですが、前に統合されてしまいました。
そのかわりFTPに対して、ログインを試みると「ログイン履歴」に
「ジオシティーズ（※）」として日時、接続元IP、認証結果などが表示されるので、外部から攻撃されたときは分かります。
ただし、今回のウィルスは感染時自分のPCからFTPで書き換えることもあるので、自分のログインと区別はつきません。
# いろいろ考えたけど一番安全そうなのは、「NET未接続/外部メディア系一切使用不可のPCからCD/DVDを焼いて
# 表面にサインを書きサーバ担当に郵送する(サーバーが同じ建物ならサイン郵送は不要)」ぐらいしか思いつかなかった
私が言うのもなんですが、Windows 2000以上ならメモ帳でできますよ
ただし、もれなくBOMがついてきます。
な、なんだって！
ローカルから google.comへ普通にクエリー送って使ってたのでgoogle.comは表示できるものだとばっかり思ってました。
いやはや、すみません。
うちだとgoogle.co.jpに飛ばされるけど、国別なのかとおもって実験してみました。
言語設定を英語優先にしてもgoogle.co.jpの英語版画面になっただけでした。
USなプロキシ通してみたらgoogle.comに飛ばされました。
IPアドレスから国別のドメインに飛ばしているみたいです。
なんていう特別待遇。
私もたまにそういうこと考えます。
地下鉄のトンネルの向こうからくる電車のライトって
飛び込みたい誘惑に駆られますよね。
でも迷惑かかるし飛び込む勇気もないという。
ほかの自殺方法も面倒です。
いやほんと、死んでも迷惑かかるし、生きてても迷惑かかるんで
どうしたら良いんでしょうね。
簡単に死ねて迷惑かからないものがあったら、紹介してほしいです。
うつ病を全員殺したとしても、
遺伝じゃないので結局患者は発生しつづけるので
淘汰は不可能だと思います。
ただ、自殺願望があるうつの人は多いとおもいますので、
簡単自殺請負サービスみたいのを始めて
外出する元気のある状態の人は訪問セールスでもすれば
ある程度参加してくれるんじゃないですかね。
#自分の葬式費用もないけどID
犯人はmoriwaka -- Anonymous Coward