ちゃっぴの監禁部屋

Session 資料の調査をしていたら、こんな資料見つけました。

アプリケーション開発者向け MicrosoftR Windows 7 対応アプリケーションの互換性

開発者必見ですね。

「System::String constructor」とかの絡みでいろいろ実験やっていたんですが、その時に遭遇した現象。Code はめちゃくちゃなのでその点ご了承ください。

ref class System::String 
{ 
public:
  String(signed char * buffer);
};

int main(array ^args)
{
  char str[] = "あいうえお";
  System::String ^ clrString = gcnew System::String(str);
  return 0;
}

結果は。

error C2664: 'System::String::String' : 1 番目の引数を 'char [11]' から 'signed char *' に変換できません。

んで、こんな感じにしてみると。。。

  signed char str[] = "あいうえお";

なんと。。。Microsoft(R) C/C++ Optimizing Compiler が落ちます。

問題の署名:
  問題イベント名: APPCRASH
  アプリケーション名: cl.exe
  アプリケーションのバージョン: 15.0.30729.1
  アプリケーションのタイムスタンプ: 488ef6ea
  障害モジュールの名前: c1xx.dll
  障害モジュールのバージョン: 15.0.30729.1
  障害モジュールのタイムスタンプ: 488f296d
  例外コード: c0000005
  例外オフセット: 000f4432
  OS バージョン: 6.0.6002.2.2.0.256.4
  ロケール ID: 1041

Visual Studio 2008 Professional Edition SP1 にて確認。

Compiler って落ちていいのかな。。。

ネタ元: System::String constructor

当初の疑問点は 2 つありました。

• MSDN の見出し「String コンストラクタ (SByte*)」がわかりにくい
• String(signed char *) となっているのに signed char[] を渡すと compile error

で、これを調査しているうちに「char と signed char」で書いたように char と signed char は compile option "/J" に関わらず別ものであるということがわかりました。理由は「charは虚数ですか?」で comment されました。

# re: charは虚数ですか? 2009/06/15 1:53 egtra

X3014:2003の3.9.1 基本型の中に「単なる文字型(char)、符号なし文字型(unsigned char)、及び符号付き文字型(signed char)は、三つの別々の型とする」という規定がありです。

なんでこんなことするんだろう？って疑問は尽きませんが。。。

で、いろいろ実験しているうちに String(signed char *) は間違いで、C++/CLI では String(char *) であるということがわかりました。

とりあえず、「String コンストラクタ (SByte*)」に書かれている内容は間違っていますね。

また、egtra さんの実験により C++/CLI では System::String(System::SByte *) もつぶされていると推測できる現象が確認できました。

ここから導き出せる結論としては、System::String constructor は C++/CLI とその他の言語で overload が全く別物になっているということです。

ということで、System::String constructor は String(char *) や String(wchar_t *) として新たに目次を起こすべきだと思います。

ネタ元: 横持ちと縦持ち_その後2_SQL文は侮れない

表題のとおりなんですが、ad-hoc query なんてものは無くしちまえ！というのがおいらの意見。

唯一の例外は、運用や試験目的で sqlcmd を発行する時くらいでしょうか。

SQL 構文を教えるのが目的なら当然必要ですが、別の言語からの呼び出し方を教えるなら ad-hoc query を発行するやり方を教えると有害な面の方が大きいと思う。

というのは、下記弊害があるから。

• SQL injection

  Parameterized query を利用したからと言って SQL injection 全てを防げるわけではありませんが、間違いなく有効な方策です。SQL injection を防止するためには、parameterized query の発行方法と LIKE での escape を教えればいいかと。これをやっておくと code review で脆弱性を探すのが圧倒的に楽になるという利点も生まれます。何も考えずに ad-hoc query を発行した場合の結果は言わずもがな。

• Compile 時間の増大

  Ad-hoc query の場合、procedure cache に一致したものが無いとその都度 compile されます。この procedure cache というのが厄介で、SQL Server の場合、parameters が一個でも違っていたら一致しないのは当然として、case-sensitive なので SQL 構文が大文字小文字で異なっているだけで一致しないと判断されます。

• Cache 有効活用

  SQL Server 64 bit 環境だと procedure cache が事実上無制限に拡張します。32 bit 環境だと Windows 32 bit 環境の制約により 2 GB までに制限されていましたけど。ということで、procedure cache が無制限に拡張されるため、本当に必要な data cache 領域が圧迫されて cache を有効活用することができません。

もっとも、上記弊害まで一緒に教えるなら問題ないんですけどね。

このような問題があるので、この手の書き方を教える場合、ad-hoc query 発行方法は必須では無いです。ほとんどの処理は parameterized query で代用できるのでこっちこそ必須とすべきでしょう。両方ちゃんと教えるならともかく、ad-hoc query 発行方法だけ教えるのはあり得ない。

なお、上記は SQL Server 2005 までの環境を前提にしています。SQL Server 2008 ではちゃんと確認していないのでどなたか確認をお願いたします。おそらく同じだと思いますけど。。。

Visual Studio では compile option 「char 型を既定で unsigned (/J)」によって変わりますけど、/J を指定していない場合、char と signed char は同じだと思っていました。ところが。。。

signed char string[] = "あいうえお";
char * pString = string;

この結果は

error C2440: '初期化中' : 'signed char [11]' から 'char *' に変換できません。

上記 error で失敗します。

下記はあまりにも当然ですけど、成功します。

char string[] = "あいうえお";
char * pString = string;

上記は Visual Studio 2008 Professional Edition SP1 で確認しています。

Compile option に /J をつけていない場合、char == signed char (typedef char signed char な感じ) だと思っていたけど、違うみたいですね。なんの目的があるんでしょう？

String コンストラクタ を読んでいて思ったこと。

わかりにくい！

例えばこれ！ String コンストラクタ (Char*)

Char * って System::Char なので Unicode だろうから、WCHAR すなわち wchar_t というところまではすぐにわかるけどね。System::Char の pointer って正直何よ？ って感じが。。。

とはいえ、C++ の宣言は下記になっているから許せるけど。

[CLSCompliantAttribute(false)]
public:
String(
    wchar_t* value
)

でも、最初に探すとき wchar_t * (WCHAR *, LPWSTR) で調べると思うんですよね。C++/CLI 以外でこんな constructor まず使わないと思うので、wchar_t * でいいんじゃないかと。

もっとわかりにくいのは String コンストラクタ (SByte*) ！ 何これ！ System::SByte 構造体 なんて普通知らんじゃないかな？

で、参照すると IEquatable 。 ふむふむ、signed char と互換性があるのね。って、ここまで references 掘り下げないとわからないのかよ！

String コンストラクタ (signed char *) にしてくれないかなぁ～と。

ここまでやってようやくわかったんだけど、要するに System::String constructor 使って Unicode だろうと MBCS だろうと C の文字列から System::String に変換できるのね。

char string1[] = "あいうえお";
wchar_t string2[] = L"あいうえお";
System::String ^ clrString1 = gcnew System::String(string1);
System::String ^ clrString2 = gcnew System::String(string2);
System::Console::Write("MBCS:\t{0:s}\nUnicode:\t{1:s}\n", clrString1, clrString2);

上記ができる説明をしたつもりだったけど、実際は全然違うみたい。

signed char string1[] = "あいうえお";

にすると compile eroor になるし。。。正確な情報どなたか教えてください。

わんくま同盟 東京勉強会 #34 での小松さんの session が面白かった。

当日突っ込もうかな？ と思ったんですが突っ込む機会を逃してしまったので blog に書きます。

Netscape VS Microsoft

これを語る要素としてはいくつかありますが、下記が大きなところかな～と。

• Internet Explorer の OS 標準搭載

  まあ、事実上無償化したわけで、Netscape つぶしが目的だったのは間違いないです。

• Netscape Navigator の失敗

  Table の扱いとかで Inetnet Explorer に移行した人も正直多いと思う。

なお、現在騒がれている Web 標準ですけど、当時はそんなもん誰も意識せずに使えそうな技術があれば先に実装して、それを標準化しようとしていた時代です。ここら辺は下記書籍を読むと経緯がよくわかるかと。

まあ、そのころおいらは IT 系から離れていた時期なので詳しいことはよくわかりませんが。。。

Cloud

いろいろな意見はあると思いますが、cloud が利用されるかは別ににして最終的に SaaS (service に対して課金) で落ち着くんじゃないかと思っています。

現在、国内の多くの企業は独自の業務 processes のため独自の applications を構築していますが、費用対効果を考えた場合これでは正直やっていけなくなるんじゃないかと。。。

もう一つ理由があります。現在 IT 技術は非常に複雑になってきており、自社でそれを全部見ることは非常に難しくなってきています。自社で完結するとなると当然それなりの skill を持っている人を確保せねばならず、それが大きな費用としてのしかかってきます。運用費用も馬鹿になりません。

Security 面での反論もあるでしょうが自社の金庫にお金を格納するのと、銀行の金庫にお金を格納するのと同じ問題に思えてなりません。Security を本当に考慮するならば、信頼できる (専任の security engineer がいる) 企業に data を預ける方がよっぽど安全だと思います。ここ数年で大きく変わるんじゃないかと正直思っています。

DB

Cache server の重要性が増し、RDB はすたれ cache server が重要になってくるという意見でしたが、正直これはどうかな？ って思います。Read only な data なら cache server の効果はそれなりにあると思いますが、read only でない data を扱うとなると RDB に代表される DBMS の重要性は変わりません。

それから cache server のお話ですが、全てを cache させるとしてそれを効率的に検索させる手法はどうするのか？ って問題も生まれると思います。複雑な演算を行うため、その演算結果を cache で持たせるということなら効果は絶大でしょうが、そういった処理はむしろ少ないんじゃないかと思います。また、cache すべき data が大量の場合、性能面も気になります。大量の物理 memory を搭載するのであれば、on memory DB という選択肢も生まれてきます。

RDB 以外が有力な選択肢になるという意見は RDB 以外を扱ったことが無いため、意見は控えさせていただきます。RDB 以上の性能が叩きだせるか？ ってのが大きな問題かと。

なんてことを session 聴きながら考えていました。

ネタ元: IIJ、ノートPCの情報漏えいを防ぐ「IIJ PC盗難・紛失対策ソリューション」を開始

ソリューションの構成要素

1. NLG（データ通信カード）
2. IIJモバイル（3Gモバイルデータ通信サービス）
3. ゲートウェイサーバ

ちとまてぇい！そりゃ solutions といわんぞ！ Solutions ちゅうもんはそもそも顧客へいくつかの選択肢を提供しておいて、顧客の要求に応じて組み合わせるもんです。
# って、ことを教えてもらったのは当時付き合いがあった非常に優秀な営業の方でしたっけ。。。

で、本題の serivce ですけど disk を抜いたらどうなる？ とかいろいろ突っ込みどころはあるけれど。。。

それはさておき、重要なのは確実に制御できるかではなく、どれだけ実効性があるか？ です。

無尽蔵に費用をかければ、いくられでも secure になるのは当たり前！
重要なのは、いかに費用をかけずに実行性を挙げるか！ です。

そういう意味ではそれなりにいい線いっていると思う。

でも、まあ現状だと問題が生じたときの費用を払った方が安い場合も多いかもね。
信頼低下まで含めるといいかんじに落ち着くかな。

ネタ元: Linux Kernel Watch 5月版　Firefoxのプチフリーズ問題から始まった大論争

Linusいわく、「上述のブロックレイヤの改善でだいぶ速くなったけれど、まだ足りない。そもそも現代において、ordered modeは適切なデフォルト値なのか」と問い掛けました。

　従来ordered modeは、クラッシュ時にinodeが不正なブロックを参照していることがないことが保証されているため、セキュリティ上好ましいとされていました。writebackでは、消したデータがなぜか復活してしまい、第三者に閲覧可能になってしまう事態が起こり得るからです。

　しかし、ハードウェアの値段が下がった結果、世の中のLinuxシステムの99％はマルチユーザーでは運用されていません。自分のデータが自分から見えるだけならば、セキュリティリスクではない、というわけです。

　この提案にはさすがに賛否両論巻き起こりましたが、「マルチユーザーを想定する必要があるエンタープライズ系ディストリは、自分でデフォルト設定を変えたらいいだろう」ということになり、コミュニティカーネルとしてはext3のデフォルトはwritebackに変更されました（注3）。

世の中の linux system の 99 % が multi user ではないと？ Linux ってまだまだ server 用途が主じゃないかと思っていましたけど、最近はそうでもないようなんですね。でも、99 % が server 用途で使っていないというのはとても信用できないんだけどなぁ。。。おそらく enterprise 向け以外の distribution という単語が抜けていると思いますが。。。それにしても、そんな危うい使い方しているのか。。。

なお、既定を ordered から writeback に変更したところで、現実にはそれほど大きな問題は無さそうだ思っていることは付け加えておきます。

Windows Server 2008 R2 を試していますが、RC にも関わらず非常に完成度高いですね～。

全般的には満足なんですが、いくつか非常に気に入らない点が。。。

一番気に入らないのは Explorer で新規 folder を作成するところ。

いちいち mouse 使うのめんどくさいので、Windows 2000 以降は [Alt] → [F] → [W] → [F] で行っていました。これが Windows Server 2008 R2 (Windows 7) になると [Alt] → [F] → [X] → [F] になっている。これが押しにくいんだな。。。

なんで、変えるんだよ！ってゆうかこの処理こそ shortcut key の割り当てが必要な処理だと思うんだが。。。

あと、本当は各種 dialog でも同じ操作で folder 作成させて欲しいんだけどね。

ちなみに Windows NT 4.0 も違っていたりする。何だったかはもう忘れたけど。