日々の破片

_ 昨日（実際は一昨日）のネタ

今、どうやらCOBOLプログラマのJavaシフト（メインフレームの置き換え対象のマシン上での作りこみが主にJavaによって為されているらしいということから）が進んでいるそうだ。

しかも、彼らはどうJavaで記述すれば良いか迷いに迷っているらしい。

PIC Xが無い。

確かにそれは大変かも。

注）忘れちゃったから、すごくいい加減。雰囲気のみ

 01 print-line.
    03 name pic x(8).
    03 filler x(2).
    03 occupation x(32).
 ...
 move input-name to name.
 move input-occupation to occupation.
 display print-line.
 ...

というようにCOBOLだとテンプレートを使えるのに、Javaだと

StringBuffer sb = new StringBuffer(8 + 2 + 32);
sb.append(input_name);
sb.append("  ");
sb.append(input_occupation);
...

としなければならないだけならいざ知らず、COBOLと異なりバイト数（この場合、桁数と考える）と文字数が一致しないという「不具合」がある。

桁数が出てくるのは固定ピッチフォントを利用した80×24の端末に表示する場合を想像すること。要するに、半角(1バイト=1桁)と全角(2バイト=2桁)という考え方が有効なデバイスである。このようなデバイスに対して「文字数」というのはハンドリングしにくいのだ。特に、half-widthカタカナと漢字が混在するような場合。

というような話ではなく、こんな感じの本はどうかな、というような話。

……（承前）……もうお気づきのように、Javaには、明示的なData DivisionとProcedure Division の区別がありません。これは、データとコードをきちんと分割し、仕様化し、管理するという優れたソフトウェア工学上の観点が欠落しているからです。このような言語上の欠陥については、きちんとコメントを記述することで回避しなければなりません。

そのため、正しくは、以下のように記述する必要があります。

// コンパイルエラーにならないためのおまじない
class CobolIsGood {
 /**
  * Data-Division.
  */
public static int count_value_1; // 4 bytes comp-5 pic 9(8)
public static int count_value_2; // 4 bytes comp-5 pic 9(8)
...
/**
 * procedure-dirivison.
 */
public static void main(String[] /* using */ args) {
   count_value_1 = args.length;
   count_value_2 = 0;
   do {
     /* perform */ proc_12(args[count_value_2]);
     count_value_2 = count_value_2 + 1;
   } while (count_value_2 < count_value_1);
}
// おまじないの}を忘れずに
}

とか。で、後半はXDoclet使いまくってpublic staticを付けずに済ませるかとか。

で、こういうのが冗談で言える環境ってのは結構なことで、どうも本気でこういうのがあるらしい――もし、本当なら、そんな本はどこにも無いから困りそうだな、じゃあ、いっちょ、そういう本を書いたら売れるかも、とか。でもその場合は、エイリアスを著者名にしないと恥ずかしすぎるよね、とか。

追記：冗談としても「本に書く」というのはいかがなものか? とは言うものの中期(3年くらい)的な見地から、本当にCOBOLで構築しかしたことがないシステム部と専用の下請けあるいはシステム開発子会社という組み合わせで、かつプロジェクトマネージメントが自社、かつ俗流ウォーターフォール(=鯉の滝登りリスク検討なし。しかし、恋が滝をのぼれば龍になれるんだがな)でマネージメントをすると意思決定が為されていて、かつ、文書/ソフトウェア管理が記号流なら、OOの出る幕はないし、かえって混乱の元(＝不幸の始まり)な気はする。

と書いて気付いたが、メインフレーマーがそのての会社の企業教育用マニュアルとして既に作っていたりして。うむ、もしそうなら読んでみたいぞ（で、読んだら感銘したりして。その徹底振りに）。

というのも、管理手法がそのままでOOでいったら出来上がるソースは

class P_03_0212 extends P_02_0001 implements P_01_0353 {
    private P_03_O211 p_03_0211;
    public P_03_0212() {
        int i_01_0001;
        int i_01_0002;
        p_03_0211 = new P_03_0211();
        if (get_V_01_0353() == C_03_0150.I_01_0589) {
            i_01_0001 = p_03_0211.proc_0353();
        } else {
            ....
        }
    }
    protected P_01_0250 get_V_02_0123() { 
        return p_03_0211;
    }
    ....
}

みたいだったりしたら、まだ、staticだけで、他のクラスとインタラクションしないほうがメンテしやすそうだからな。

_ 見たい

モグラの動画見てみたい。もこもこふわふわしゃりしゃりという語感がいいなぁ。

_ 難読化

ふと思いついて難読化を調べてたら詩に出合ったり。

さらには、あんまり知られていない(という訳語を当てれば良いのかな)セキュリティイシューとか。

_resetstkoflwって2001年のMSDNには出てないってことは、/GSと同じくVC++.NETからなのかな? って言うか、しっかりDLLヘルになってるが、XPからなのか。いつもながらにちょっとずるい感じだが。

全言語のページから_resetstkoflwを検索しました。 約44件中1 - 20件目 ・検索にかかった時間0.11秒

翻訳もされてた。

うむ、正解だった。が、こんなにおもしろいのに、続きはないのかなぁ。

っていうか、memsetサイコー。

というわけで、リンクを読まずに、上のヒントから、次の問題(全部引用)を解いてみましょう。

このコードを Microsoft Visual C++® .NET でコンパイルして、このコードに欠陥が見つかるかどうか調べてみてください。

BOOL DoStuff() {
  char pPwd[64];
  size_t cchPwd = sizeof(pPwd) / sizeof(pPwd[0]);
  BOOL fOK = false;
  if (GetPassword(pPwd, &cchPwd)) 
     fOK = DoSecretStuff(pPwd, cchPwd);
  memset(pPwd, 0, sizeof(pPwd));
  return fOK;
}

ヒントをあげましょう。コードには何も悪いところはありません。期待どおりに記述されています。ユーザーのパスワードが取得され (この例では、パスワードを取得する方法は問題ではありません)、そのパスワードを使って何らかの重要な操作が実行されます。作業完了後に、パスワードの全バイトがクリアされます。

....

ZeroMemoryってのはWin16時代の互換性用のAPI(CRTの欠落を補うための)だと思って敬遠していたこっちが間抜けだったようだ。WinBase.hをちゃんと見なきゃな、というか、Win32 APIを使えというますますソース互換性を失わせる罠でもあるが。

追記：

日本は2002年で止まってるが、msdn.microfot.comだと、Security-Security(General)-Columns-Code Secureで連載は続いている。最新は2004/1で、担当がデイヴィッドルブランってのに変わってるけど(ただしマイケルハワードによる紹介文つき)。

っていうか、このコラムがおもしろい理由の1つは、

〜は脆弱性の原因となる。たとえば、MS03-xxxxは、まさにこれが原因だ。では解説しよう…… と、妙にナマナマしいからだな。