2017-08-28

麻布十番で職務質問を受けた話

残暑も残る8月27日の日曜日のことであった。その日、私は知人のぽんこつさんが自宅でボードゲーム会を行うというので、昼からぽんこつさんの住んでいる麻布十番に出かけた。

ぽんこつボドゲVer17.08 - connpass

その日の私の出で立ちは、7月3日に受けた違法な職質のときと同じ、帽子、即乾シャツ、即乾アームカバー、デニム生地風ストレッチパンツ、半長靴であった。

本の虫: 警察官に職務質問をされた話

また、リュックの中にはボードゲームを満載し、かつボルダリングの道具も入れていた。これはぽんこつさんの自宅近くにスパイダーというクライミングジムがあり、ボドゲ会が終わった後に行こうと考えたためである。

約束の12時に間に合うよう、余裕を持って家を出たつもりであったが、待ち合わせ場所の麻布十番駅についたときにはすでに12時20分。ぽんこつさんの姿は見当たらない。

これはうっかり出遅れた。ぽんこつさんとボドゲ仲間達は今頃、どこかの飲食店で昼食を取っているに違いない。私は携帯電話を所有していないため、ぽんこつさんに連絡を取るのが不可能だ。しかし、私はぽんこつさんの自宅を知っている。単独で向かえばよかろう。そう判断した私は、道中のコンビニで軽食を買い求め、ひとりぽんこつ宅に向かった。

ところで、麻布十番というのはやや特殊な場所である。極めて地代が高く、およそ人の住む場所ではない。ぽんこつさんは職場がどこであれ、職場近くに住むという強い信念を持っている人だ。しかし、さすがに麻布十番という場所は、優秀なエンジニアである彼の少なからぬ給料から考えても、やや家賃が高いはずだ。第一周辺環境が人が住むのにまるで向いていない。例えば、麻布十番には安いフランチャイズ店 の牛丼屋がない。麻布十番という地代は牛丼屋で利益を見込めないからであろう。一方、マクドナルドはある。マクドナルドの価格帯からすると、麻布十番に出店するのは大赤字のはずだが、おそらくこれは「マクドナルドはどこにでもある」という雰囲気を出すための広告の目的も兼ねて出店しているのであろう。

また、麻布十番は、路上にやたらに警察官が警備に当たっている。これはどうも、麻布十番には諸外国の大使館が多いためらしい。また、当日は麻布十番で祭りが開かれているらしく、いつもに増して路上に立つ警察官の数が多かった。

さて、ぽんこつさんの自宅についたが、あいにくとインターホンに応答がない。どうやらぽんこつさんとそのボドゲ仲間たちは、まだ昼食に出かけているようだ。さてどうしよう。

すでに書いたように、私は携帯電話を持っていないので、ぽんこつさんと連絡が取れない。この場を離れると、ぽんこつさんと入れ違いになってしまう可能性がある。ぽんこつさんはせいぜいあと2,30分もすれば昼食から帰宅するはずである。すると、私の取るべき最適な行動は、ぽんこつさんの自宅近くの路上でぽんこつさんの帰宅を待つということになる。そこで私は、自宅近くの路上に座り込み、コンビニで買った軽食をつまみながらぽんこつさんの帰りを待っていた。あいにくと現場は民家と接客を伴わない何らかの事務所などしかなく、ぽんこつさんの自宅を視界に収めることができる喫茶店のたぐいは存在しなかったからだ。

そのまま10分か20分ほど軽食を使いながら待っていると、路上に立っていた警察官がこちらに歩いてきた。

「さきほどからここにとどまっていますが、ここで何をしているのですか」

この警察官は私が先日違法な職務質問を受けたかどで国賠訴訟を提訴した人物であるとは思いもよらないはずだ。私は吹き出しそうになるのをこらえながら答えた。

「人を待っています。私は携帯電話を持っていないもので連絡を取る手段がないのです」
「荷物の中身を見せてもらっていいですか」
「なるほど、この場合は妥当な理由があると私も認める状況ではあります。見せましょう。しかし・・・」

と、ここまでいいかけたところで、ぽんこつさんとボドゲ仲間たちが道の向こうからやってきた。彼らは私と警察官が話し合っているところから、状況を一瞬で察したらしく、爆笑しながらやってきた。

その後、路上とぽんこつさんの自宅に入ってからもしばらく、我々の爆笑が止まらなかったことはここに書くまでもないことだ。その後、我々はボードゲームを行い。解散後、私はクライミングジムに行って、そして帰宅してこれを書いている。

これで私の人生において職質を受けるのは4度目だ。今回の職質は、その文脈上、開始するにあたって妥当な理由があると私も認めざるを得ない。さりながら、やや気になる点がある。私が「しかし」に続けて警察官に言おうとしたが、仲間が来たために言いそびれたことだ。

職務質問の根拠法である警察官職務執行法は、停止させて質問ができると書いてある。所持品の捜索ができるとは書いていない。所持品の捜索は憲法35条が令状なくしては行えないと定義するものであって、通常ならば令状のない所持品の捜索は違憲である。

しかし、過去の判決により、職務質問に付随して令状なしの所持品の捜索は違憲ではないという判例が存在する。しかし、あくまで、「職務質問に付随」して行えるものであり、当初から所持品の捜索を目的として行えるものではない。

今回、警察官は私の所持品を捜索すべき理由を何も告げずして、単に「荷物の中身を見せろ」と言った。これは職務質問に付随して行ったものであろうか。職務質問に付随して行うと言うからには、質問の過程で所持品の中身を改めることによって犯罪の有無を明らかにできると判明した場合に行うべきだろう。今回の職務質問は、単に私が何をしているか質問し、その答えを聞いただけで、突如として何の脈絡もなく、理由もなく、「荷物を見せろ」と言ったのであって、果たしてこれが職務質問に付随したものであると言えるだろうか。

警察官職務執行法には令状なく所持品の捜索ができるとは書いていない。私が過去に四回受けた職質では、皆同様に何の脈絡もなく即座に所持品の検査を要求されている。本来ならば憲法35条に違反する令状なしの所持品の捜索がこのようにたやすく行われる現状はおかしいのではないか。

2017-08-19

LLVMがWindowsのデバッグ情報フォーマットのPDBをサポート

LLVM Project Blog: LLVM on Windows now supports PDB Debug Info

この数年、clangをWindowsでソフトウェア開発するための世界級のツールチェインにするために尽力してきた。このことについては、すでに何度も書いてきたことだ。LLVMは完全なABI互換を実現した(ただしバグ互換ではない)。互換性を実現するのが難しい分野にデバッグ情報があるが、この2年間で、LLVMは飛躍的な発展をとげた。とりあえず結論を先に書くとこうだ。WindowsでClangを使うと、PDBデバッグ情報が出せる。

背景:CodeView VS PDB

CodeViewは1980年台の中頃にMicrosoftによって考案されたデバッグ情報フォーマットだ。様々な理由で、他のデバッガーはDWARFという独立したフォーマットを開発し、これは標準化されて、多くのコンパイラーとプログラミング言語でサポートされている。CodeViewは、DWARFと同じく、ソースコード行とコードアドレスのマッピングと、プログラムが使う型とシンボルのレコード集である。デバッガーはこの情報を使って、関数名でブレイクポイントを設定したり、変数の値を表示したりする。ただし、CodeViewはあまりよくドキュメント化されていない。最新の公式なドキュメントは少なくとも20年前のものだ。レコードの中にはドキュメント化されているものと同じフォーマットのものもあるが、まだドキュメント化されていない後々の追加のレコードもある。

ここで重要なのが、CodeViewは単にレコード集だということだ。もしユーザーが、「Fooの値を表示してくれ」といったときどうなるだろうか。デバッガーはFooについてのレコードを検索する。そして物事は更に複雑になる。どの最適化が有効にされていたのか? コンパイラーのバージョンは?(これはコンパイラーのバージョンによって一部のABIの非互換があったり、極度に最適化されたコードからバックトレースを再現する際のヒントとして使ったり、スタックが破壊されているかどうかの確認に重要だ)。プログラムには大量のシンボルがある。どうやって遅いO(n)にならずにシンボルを検索すればいいのか? どうやってコードを僅かに変更した時にインクリメンタルリンクを実現してデバッグ情報の再生成を回避すればいいのだ? 文字列の重複を省いて空間を節約するにはどうすれば? ここでPDBが登場する。

PDB(Program Database)は、その名前通り、データベースだ。これにはCodeViewが含まれているが、CodeViewレコードを様々な方法でインデックス化するための様々なものが含まれている。これによって型やシンボルを名前やアドレスで検索するのを高速化している。発想としては入力ファイルに対する「テーブル」と同等であり、ユーザーはその存在を気にすることはないものの、Windowsにおけるデバッグを快適にするのに貢献している。しかし問題がある。CodeViewはある程度はドキュメント化されているのに対し、PDBはまったくドキュメント化されていない。しかもその構造は複雑だ。

お手上げだ(ホントか?)

数年前、LLVMは開発の方向性として、CodeViewとPDBを出力する望みを一切捨て去り、以下の2つに注力することにした。

  1. clang-clはWindowsでDWARFデバッグ情報を出力する
  2. LLDBをWindowsに移植してWindows ABIに対応させる。これはVisual StudioやWinDbgをDWARFに対応させるより遥かに簡単だ(そもそもそんなことが可能であればの話だが。Visual StudioとWinDbgの拡張機能を使って実装可能なのだろうか)

実際、私はすでにブログ記事でこのことを2年前に書いている。作業の結果、LLDBをWindowsに移植して簡単なデバッグをさせることはできるようになった。

残念ながら、PDBのサポートは必須であることが明らかになった。LLVMの目標はWindowsエコシステムに囚われた開発者にとってできるだけ抵抗が少なくなるようにすることである。Windows Performance AnalyzerやvTuneのようなツールはとても強力でエンジニアの慣れ親しんだものである。企業はPDBファイルを保存、収集してクラッシュダンプを解析するインフラに投資している。PDBによるデバッグはとても高速だ。というのも、インデックスはファイルフォーマットで実現されていて、デバッガーが起動時にシンボルをインデックス化しなくてもいいためだ。それに、WinDbgのようなツールはすでにデバッグ用途に便利で、率直に言って、多くの(おそらくはほとんどの)Windows開発者がVisual Studioを手放すためには、彼らの死体の手からもぎ取る必要があるだろう。

私がとりあえずMicrosoftに協力を求めてみればええんちゃうと提案したときには皆から冷たいまなざしを受けたものだ。しかし、最終的に我々はMicrosoftに協力を求めた、そしてMSは協力した。協力はMicrosoft Githubにコード片を投下するという形で得られた。後はこのコードを解析するだけだ。Microsoftが公開できたコード片はPDBのコードの一部(我々は推測と解析をしなければならないし、そもそもコードは半分ぐらいかけているのでコンパイルすら通らないわけだが)だけであるが、実装をするだけの情報は得られた。

このコードを1年半解析し、試し、更に解析し、更に試しなどした結果、lld(LLVMリンカー)はついに機能するPDBを出力することができるようになった。基本的なことであるコード行や名前でのブレイクポイントの設定や、変数の表示や、シンボルや型の検索は、すべて動くようになった(ただし、もちろん、バグ互換はない)

PDBの詳細を調べたい人のために我々はツールも開発中だ。llvm-pdbutilと呼ばれるツールで、Microsoftのcvdumpユーティリティとよく似たものだ。このツールはPDBの内部情報をダンプして、PDBとyamlの相互変換、2つのPDBのdiffなどを実現している。llvmpdbutilの簡単なドキュメントはここにある。PDBファイルフォーマットの詳細の解説はここにある。この2年間に我々が解析したすべてが書いてある(まだ途中だ。私はドキュメントとPDBの実装の両方に時間を割かなければならないのだ)

バグをもってこい!

さて、ここで読者の協力が必要となる。我々はPDBで簡単なデバッグ状況をテストしたが、まだデバッグ情報の品質としてはアルファ段階だと考えている。是非試して、問題をバグトラッカーで知らせてほしい。始めるためには、まず最新のWindows用Clangのスナップショットをダウンロードしよう。この機能をテストする簡単な2つの方法は以下だ。

  1. clang-clにlldを自動的に実行させる

    clang-cl -fuse-ld=lld -Z7 -MTd hello.cpp

  2. clang-clとlldを別々に実行する。

    clang-cl -c -Z7 -MTd -o hello.obj hello.cpp

    lld-link -debug hello.obj

バグレポートがあふれかえるのをお待ちしております!

Microsoftが我々に協力してgithubレポジトリにコードをアップロードしてくれたことに心から感謝している。Microsoftの協力なしには実現できなかったことだ。

ところで、将来期待される歓喜すべきある事柄について読者の想像に委ねたい。ここに書いたPDBサポートはWindows特有のAPIやdllやライブラリに一切依存していない。100%移植性がある。ところで、君はクロスコンパイルに興味があるかね?

Zach Turner(LLVMのWindowsチームとして)

なかなか興味深い。

ところで、Microsoftが公開したMicrosoft/microsoft-pdbはMSVCのPDBを処理しているコードの一部だ。PDBフォーマットの詳細を開示するよう要請したところ、コード片が開示され、しかも、Microsoft自ら、「ソースコードは究極のドキュメントである」"Source code is the ultimate documentation :-)"、書いているところを見ると、果たしてMicrosoft社内にPDBの詳細なドキュメントはあるのか疑問だ。

OracleがJava EE 8の開発をコミュニティの手に委ねたいとか言い出す

Opening Up Java EE | Oracle The Aquarium Blog

Oracleがブログで、Java EE 8の開発をコミュニティの手に委ねたいと表明している。その文章がいかにも回りくどく面白かったので、とりあえず翻訳してみた。

Java EE 8についてOracleは目覚ましい進展を続けてきた。規格はほぼ固まり、この夏にリファレンス実装を提供できる予定だ。Java EE 8の提供とJavaOne 2017カンファレンスが近づいてくるにつれ、OracleとしてはJava EEの開発をより変容する業界と技術要求に対してアジャイルかつレスポンシブに対応できる開発体制を再考する余地があるのではないかと考える。

Java EEは競争的な市場において、互換性の高い実装、業界に広く採用されている技術、多大な既存のフレームワークとツール、エンタープライズとエンドユーザーに対する数限りない適用例でもって、大変に成功している。しかし、Java EEはJava EEコミュニティも参加するオープンソースで開発されているとはいえ、その開発体制は十分にアジャイルでフレキシブルでオープンではなく、特に他のオープンソースコミュニティと比較すると違いが顕著である。Oracleはよりベターにやりたい。

Oracle内部ではjava EE 8提供後のJava EE開発体制をいかにして改善できるかについて議論している。Oracleとしてはリファレンス実装とテスト互換キットを含むJava EE技術をどこかのオープンソース財団に移行するのが、よりアジャイルな開発体制、よりフレキシブルなライセンスの実現、管理体制の変革という点で、適切な方法であると信ずる。OracleはJava EEの開発をこの方向ですすめるべく、この可能性をコミュニティと我々のライセンシーといくつかの財団に掛け合う予定だ。

Oracleは開発者、エンドユーザー、カスタマー、消費者、貢献者、パートナー、ライセンシーに対する貢献を続けていく。そしてOracleは既存のJava EE実装と将来のJava EE 8実装に対するサポートを続ける。Orackeは将来のJava EE技術の発展に関与し続ける。しかし、単一のベンダーやプラットフォームの意向によらないよりオープンな開発体制は、イノベーションの促進によろしく、コミュニティの最大の関心を引きつけるところであると信ずる。

この件に関してコメントしたい人は、feedback@javaee.groups.ioにメールしてもらいたい。この件の進展についての詳細を告知する。

この件がWebLogic Serverに与える影響については、こちらを参照。

お断り

以上はOracleの一般的なプロダクトの方向性を示すものです。以上は情報提供の目的で提示されたものであり、将来に渡って何らかの約束をするものではありません。以上は何らかの財産、コード、機能の提供を約束したものではなく、購入選択において考慮すべき情報ではありませんOracleのプロダクトの機能の開発、リリース、その提供時期はOracleが決定するものであります。

Oracleの過去の前科から考えると、この手のコミュニティに開発を委ねるという方法で、市場価値の薄れてきたSolarisを殺し、SPARCを殺し、Star Officeも殺してきた。要するに旧Sun Microsystemsの製品を続々と殺し続けてきたわけだ。Java EE 8も後に続くのだろうか。

ただ思うと、JVMには未だに価値を認める人間が多いのに対し、Javaはそれほど空かれていない。だからScalaとかKotlinとかその他多くのJVMで動く言語が流行っているわけだ。JVMはともかくJavaの将来性はあるのだろうか。

2017-08-16

江添ボドゲ会 8月20日

8月20日に自宅でボードゲーム会を開催します。詳細はconnpassで。

江添ボドゲ会 8月20日 - connpass

2017-08-04

C++17の参考書がだいぶ完成してきたので査読大募集中

半年前から書き始めたC++17の参考書がだいぶ完成してきた。参考書はGitHubで公開している。不備を発見したら、どんどんPRを投げてもらいたい。すでに28件のPRを処理した。

EzoeRyou/cpp17book: textbook for C++17

昨日書きあげたばかりのC++17で追加された数学用の特殊関数の章は特に数学とC++の両方に詳しい人間の検証を必要としている。

cpp17book/045-cpp17-lib-mathematical-special-functions.md at master · EzoeRyou/cpp17book

さて、残りは小粒なライブラリと、ファイルシステムだ。

C++17にはposixのファイルシステム操作をC++風にラップしたファイルシステムライブラリが入る。これを一体どうしたものか迷っている。

というのも、ファイルシステムライブラリは膨大で、その解説には100ページ以上かかる。果たしてそんな解説をして、これ以上執筆機関を伸ばし、またページを増やしてもいいものだろうか。

とはいえ、今C++の詳細な参考書はなかなか出版が減っているし、かつC++のファイルシステムライブラリだけで一冊の本が出るとも思えないので、書いておくべきだろうか。

この参考書が完成したら、アスキードワンゴから出版をすることを見込んでいる。

ドワンゴ広告

ドワンゴは本物のC++プログラマーを募集しています。

採用情報|株式会社ドワンゴ

CC BY-ND 4.0: Creative Commons — Attribution-NoDerivatives 4.0 International — CC BY-ND 4.0