SSブログ

flexがいつのまにか更新されていた [プログラミング]

注意:adobeのflexではありません。

cygwin updateをしたところ、手持ちのプログラムがコンパイルできなくなっていました。

調べたところ、flexのバージョンがあがっていて、若干仕様が変更されていました。

現時点での最新版は 2.5.35 です。これまでは 2.5.4a を使っていました。

生成コード(lex.yy.cc)に #define yyFlexLexer yyFlexLexer という行が含まれるらしく、FlexLexer.h の #ifdef 文の動作が変わるようです。ここでハマりました。

これは、c++から使えるようにする仕組みと、複数のスキャナを並存するための仕組みを発展させた結果だと思うのですが、未だ無理矢理感が漂っていますね。c的なマクロ秘術とc++ wrapper(FlexLexer.h)が絡み合って、かなりのワケワカメ状態になっています。

あと、手持ちの過去のソースは 2.5.4a でしかコンパイルできないので、2.5.4aのソースを保存しておく必要がありそうです。
nice!(0)  コメント(0) 

XP SP3リリース?

リリース直前になって延期されましたが、MSDNでは開発者向けにダウンロードできるので、それを試しています。

以前の紹介ではパッチ累積だということだったのですが、どうやら、ホットフィックスの一部も取り込まれているようです。

ホットフィックスとは、個別に問い合わせした人にだけ提供される修正パッチです。広い範囲のテストを経ていないので、必要な人だけがあてるべきものです。

ということはつまり、SP2+WindowsUpdateしても、SP3と同じにはならないことになりそうです。

そういう意味では、しばらくはSP2+WUとSP3の2パターンが並存することになりそうです。
nice!(0)  コメント(0) 

Subversionのログ表示を速くする方法 [プログラミング]

Apache配下のsubversion(mod_dav_svn)で、クライアントからログを見ようとするととても遅く感じられます。これをスピードアップするネタです。

そのものズバリは以下のサイトの「VI.4.4.3. パス名にもとづいたチェックの禁止」にあります。

http://www.exacteye.com/svn/svn.serverconfig.httpd.html

キーワードは SVNPathAuthz off です。Apacheのアクセス権限設定を参照しないようにする、という意味です。デフォルトでは on なのですが、このとき、ログに含まれるパス1つごとにApacheにお伺いを立てているのです。ありえねえ。

試しに自宅のリポジトリサーバでoffにしてみたら、爆速になりました。

しかし、細かく権限を設定しているようなサイトでは、この方法はオススメできません。とはいえ、subversionリポジトリのサブディレクトリごとに読み書き権限を設定するような使い方は、あんまりないんじゃないでしょうか。もしかしたらあるのかな。


nice!(1)  コメント(0) 

Windows XP SP3情報

WinXP SP3情報が公開されています。

http://www.microsoft.com/downloads/details.aspx?FamilyID=68c48dad-bc34-40be-8d85-6bb4f56f5110&DisplayLang=en

解説記事はこちら

http://itpro.nikkeibp.co.jp/article/COLUMN/20071112/286915/

SP2+累積パッチって感じですね。SP2インストール後、Windows Updateで何度も再起動しなくて済むのがウリだそうで。

たくさんのPCを管理する企業ユーザ向けかな。一般人には関係なさそう。

個人的にはSMB2に対応してくれたりするとうれしかったんだけど・・・


nice!(0)  コメント(0) 

Win32 Cryptography APIでRSA public key読み込み [プログラミング]

めちゃくちゃしんどいんですけど。

RSA key pairで sign/verify/encode/decode したいだけなんですが。

どうしてこうもわけのわからないことになりますか。

イヤガラセですか。


nice!(0)  コメント(0) 

レジストリへの文字列の読み書き [プログラミング]

意外にややこしいことになっています。

書き込みの場合

RegSetValueEx APIを使います。問題は cbData 引数の値です。 MSDN にはこうあります。

[in] The size of the information pointed to by the lpData parameter, in bytes. If the data is of type REG_SZ, REG_EXPAND_SZ, or REG_MULTI_SZ, cbData must include the size of the terminating null character or characters.

俺訳。太字は俺。

lpDataパラメータが指す情報のサイズをバイト単位で指定します。データのタイプがREG_SZ, REG_EXPAND_SZ, REG_MULTI_SZの場合、 cbData には 終端ヌル文字またはヌル文字集合 のサイズを含めなければなりません。

バイト単位で、終端ヌルも含めるわけですから、UNICODE文字列でREG_SZの場合は・・・

  • × (wchar_t文字数)
  • × (wchar_t文字数)+1
  • × (wchar_t文字数)*sizeof(wchar_t)+1
  • ○ ((wchar_t文字数)+1)*sizeof(wchar_t)

最後のが正しいです。

読み込みの場合

RegQueryValueEx API を使います。

ハマりやすいのが lpcbData 引数です。受け取りバッファのサイズをバイト単位で指定するのはいいのですが、では戻り値はどうでしょう?

REG_SZでUNICODE文字列の場合は・・・

  • × (wchar_t文字数)
  • × (wchar_t文字数)+1
  • × (wchar_t文字数)*sizeof(wchar_t)+1
  • ○ ((wchar_t文字数)+1)*sizeof(wchar_t)

ということで、バイトサイズであること、NUL終端文字(wchar_tの場合バイトサイズはsizeof(wchar_t))を含むことに注意しましょう。

ところでこんな Remark があります。

http://msdn2.microsoft.com/en-us/library/ms724911.aspx

If the data has the REG_SZ, REG_MULTI_SZ or REG_EXPAND_SZ type, the string may not have been stored with the proper terminating null characters. Therefore, even if the function returns ERROR_SUCCESS, the application should ensure that the string is properly terminated before using it; otherwise, it may overwrite a buffer.

ギャー。ヌル文字加えてないアホタレがいるかもしれんからチェックしろだと。

んなことやってられっかー。ということで受け取りバッファを多めにとって、あらかじめ0fillしておくのが賢明です。


nice!(0)  コメント(0) 

ファイル名操作に便利なWin32API2つ [プログラミング]

ファイル名を扱う場合に便利な2関数。

GetFullPathName が熱い(←意味不明)。

親ディレクトリを指し示す".."や、カレントディレクトリを指す"."を「解決」してくれる。

例えば、 c:\path\to\..\toto\file.txt を食わせると、 c:\path\toto\file.txtにしてくれる。

但しそのパスが実際に存在するかはチェックしない。つまりパス名のようなものかチェックしてくれるわけだ。

ユーザが入力したパス名を正規化するの便利。

ついでに、"/"区切りも受け付ける。ただし結果は"\"区切りになる。うはは。

この手の処理をするコードを自作するのは非常に難しいのでガンガン使おう!!!

GetLongPathName も熱い(←意味不明)。

ファイルの存在をチェックしてくれる。簡易statかつロングファイル名になるので便利。


nice!(0)  コメント(0) 

Vistaでは排他の獲得順序が要求順序となることが保証されない [プログラミング]

排他はいろいろあるけど対象は Mutex, CriticalSection, Semaphore か(調べる)。

対象OSは「WinXP 64bit、 Windows Server 2003 以降」が正しい。MSDNにその解説があったはず(後で書く)。

今までは(明示されていなかったが)要求順に獲得されていたので、ある程度公平になっていた。

複数スレッドが頻繁に取り合いをするような場合に、不公平が生じる。

困る例:A,B,Cの3スレッドがあり、あるデータに排他アクセスする。Cが描画スレッドで、AとBが通常のワーカスレッドとする。A,B,Cが排他の取り合いをするため、Cが(A,Bもだけど)アクセス権を獲得するタイミングは不定となる。例えばフレームレートの維持が難しくなり、表示がガクガクする。

あるデータの例としてはログ書き込み用のバッファなど。

データベースなんかはどうなんだろう?

以下の掲示板の記事が参考になります。最初にこれを読めと。

http://forums.belution.com/ja/vc/000/399/75s.shtml

んん、以前から順序保証はないとあるなあ。


nice!(0)  コメント(0) 

プロセスデフォルトヒープとCRTヒープは別 [プログラミング]

Win32環境では、プロセスはいくつもヒープを持つことができます。

プロセス起動時に1つ作成され、プロセスデフォルトヒープとなります。GDI32やUSER32などのメモリ割り当てはここから行われるようです。 GetProcessHeap() 関数で取得します。

C Runtimeもヒープを一つ使います。malloc/free/new/deleteや、strtokなどが使うヒープです。 _get_heap_handle() 関数で取得します。

続きを読む


nice!(0)  コメント(0) 

libpng 1.2.20 リリース [プログラミング]

PNGコーデックライブラリlibpngの1.2.20が公開されています

http://www.libpng.org/pub/png/libpng.html

1.2.20ではMMXアセンブラコードが削除されていますねえ・・・

まあVC用コード(pngvcrd.c)はスレッドセーフでなかったので、事実上使えなかったわけですが。(これにはどれくらいの人が気づいていただろう?)

gcc-i686用のとVC用のと両方メンテするのが大変ってことでしょうか。単一の抽象コードから両用を生成できればいんでしょうけども。

あるいは速度差がほとんどでないのかな。


nice!(0)  コメント(0) 

この広告は前回の更新から一定期間経過したブログに表示されています。更新すると自動で解除されます。