本の虫

Mac OS X Sudo Password Bypass | Hacker News
Mac OS X Sudo Password Bypass ≈ Packet Storm

管理者権限を持つユーザーで、かつ、一度でもsudoを実行したことのあるユーザーならば、パスワードを入力しなくてもsudoが使えてしまうバグが発覚した。

sudoというのは、ご存知、管理者権限でプログラムを実行するプログラムだ。sudoを一度実行すると、しばらくの間（デフォルトでは15分間）、認証がキャッシュされ、sudoはパスワード入力なしで使えるようになる。この機能により、管理者権限を必要とする作業を集中して行う短時間の間に、何度もパスワードを入力する煩わしさをなくしている。

MAC OS X 10.7-10.8.4のsudoは、この「しばらくの間」を判定する方法にバグがあり、システムクロックを1970年1月1日（ご存知UNIX時間の起点）に設定すると、sudo -kが常に「しばらくの間」だと判定され、永久に使えてしまうバグがあるそうだ。

なんともお粗末なバグだ。

このバグは最新のMAC OS Xなら、すでに修正済みだそうだ。

追記：このバグMAC OS Xに限らないCVE-2013-1775として報告されたsudoのバグで、しかも今年に入ってから発覚したので、MAC OS X以外のOSの、結構最近のsudoのバイナリも該当する。

C++14には、decltype(auto)が追加された。これは、autoと似ているが、微妙に違う。decltype(auto)は、初期化子の式をdecltype()の中に書いたのと同じ挙動をする。

つまり、以下のようになる。

int i = 0 ;
int && f() ;

auto            a1 = i ; // int
decltype(auto)  a2 = i ; // int

auto            b1 = (i) ; // int
decltype(auto)  b2 = (i) ; // int &

auto            c1 = f() ; // int
decltype(auto)  c2 = f() ; // int &&

単に、初期化子の式がiの場合は、autoもdecltype(auto)も変わりはない。

初期化子の式が(i)の場合は、型が違ってくる。なぜならば、括弧で囲った式は、decltype指定子の中に入れると、lvalueリファレンスになるからだ。「decltype(auto)は、初期化子の式をdecltype()の中に書いたのと同じ挙動をする」と先に書いた。すなわち、この場合のdecltype(auto)は、decltype((i))と書いた場合と同じ挙動をする。すなわち、型はint &となる。

関数呼び出し式もこの影響で、型が違ってくる。

autoとdecltype(auto)には、まだ違いがある。decltypeは式から型を推定するので、初期化子に式ではないものが使われている場合、エラーとなる。リスト初期化だ。

auto            d1 = { 1, 2 } ; // std::initilizer_list<int>
decltype(auto)  d2 = { 1, 2 } ; // エラー、{ 1, 2 }は式ではない

また、decltype(auto)は、単独で使われなければ、エラーとなる。

auto            * e1 = &i ; // int *
decltype(auto)  * e2 = &i ; // エラー、decltype(auto)は単独で使われなければならない

なぜdecltype(auto)が追加されたのかというと、関数の戻り値の型をreturn文から推定する機能を、lambda式以外の普通の関数にも広げようとした結果、decltype(auto)のようなヒントがほしい場合があったからだ。

int & f() ;

// 戻り値の型はint
auto g() { return f() ; }

// 戻り値の型はint &
auto h() -> decltype(auto) { return f() ; }

decltype(auto)がなければ、ここでint &を推定させたい場合は、decltype(f())と書かなければならない。

これはとても簡単で、テンプレートが絡まない例なので、いまいち恩恵が分かりにくいかもしれない。戻り値の型は推定させたい場合というのは、関数テンプレートで、インスタンス化するまで戻り値の型がわからない場合だ。例えば以下のような。

// 関数テンプレートfはメタプログラミングやオーバーロードにより、戻り値の型が型に依存して変わる。

template < typename T, typename U >
auto g( T const & t, U const & u )
-> decltype( auto ) 
{
    return f( t, u ) ;
}

decltype(auto)がないと、decltype( f( t, u ) )と書かなければならず、コードが重複し、冗長になり、変更時に不整合になる恐れもある。

Return type deduction for normal functions

[Phoronix] The XMir Security Issue Should Now Be Resolved

XMirはVT切り替えが起こった後も入力をとり続けるため、text VTに切り替えた後ログインすると、入力されたユーザー名とパスワードがXMirを通してXのプログラムに漏れるというとんでもないバグがあったが、つい二日前のコミットで、修正されたそうだ。

mjg59 | If you ever use text VTs, don't run XMir right now

XMirはVT切り替えも入力を取り続けるので、XMirを起動したままtext VTに切り替えてログインすると、キーボード入力がXMirを通してダダ漏れになるという問題がある。

Mirベースの世界では、Mirサーバーが入力イベントを受け取って、Mirクライアントに渡すことになるだろう。実際、XMirは標準のXorg入力ドライバーを使っているので、全入力イベントを直接受け取っている。このため、XMirの初期のバージョンで見られたようなマウスポインターの重複があった。XMirで描画されたマウスポインターと、Mirで描画されたマウスポインターがあったのだ。

もっと重大な問題がある。Mirは最近、とても単純なVT切り替えの実装を得た。単に入力イベントから、CtrlとAltとファンクションキーが同時押しされたのを見張るだけだ[1]。そして、/dev/consoleに適切なioctlを発行して、カーネルにVTを切り替えさせる。ここでの問題は、MirはXMirにそのことを伝えていないという事だ。そのため、XMirは依然として入力デバイスを開きっぱなしで、入力イベントを見張り続けている。

これはとても簡単に再現できる。XMir上でターミナルとかテキストエディターを開いて、フォーカスを当てる。Ctrl+Alt+F1を押して、ログインする。Ctrl+Alt+F7を押す。ユーザー名とパスワードがウインドウに表示されているだろう。

これは6月20日に報告されたLaunchpadバグ1192843だ。一ヶ月半後、MirはmainのUbuntuレポジトリに追加された。その下に、「XMirは常にキーボードを見張っていて、パスワードが他のXセッションに現れることがある」と注意書きされている。これは誤解しやすい書き方だ。何故ならば、「他のXセッション」という記述から、複数のXセッションを実行しなければ起こらない問題のように読めるからだ。とにかく、これは既知のバグであり、ユーザーのパスワードを漏らす恐れがある。

これが唯一の注意で、「VESAじゃ動かない」とかの議論の下に埋もれているのは不思議だ。インストールガイドのリンクをたどるとこのページに行き着くが、この問題については記されていない。まあ、Mirのその他の問題についても記されてはいないのだが、他の問題は、単に動かないといったもので、パスワードがIRCに流されるというたぐいの問題ではない。

これが開発途中のソフトウェアだからだというのは言い訳にならない。CanonicalゆえにMirはかなりの知名度があり、いずれテストされるだろう。明確で明示的な警告がないのは弁護の余地がない。この問題が修正されるまで、このようなパッケージがアーカイブに含まれてはならないのだ。これはCanonicalのありないほど無責任な行動である。

そういうわけで、text VTに切り替えるといったことをしているのならば、切替時にはXMirを実行しないようにするか、Xから離れる時、すべてのネットワーククライアントからフォーカスを外すようにしておけ。すでに問題を犯していないかどうか、既存のIRCやIMのログを確認するのも忘れずに。

[1] Xのあまり知られていない機能としては、VT切り替えイベントは、keymapで設定されているということだ。Ctrl+Alt+F1はデフォルトでVT1に切り替える。任意のキーの組み合わせで任意のVTに切り替えるよう設定することもできる。でも、XMirだとキーストロークを直接扱うので、そういう設定はできないがね。

http://jabirproject.org/

イラン産のJabirOSというものがある。これは、以前はUbuntuベースだったが、なんとFreeBSDベースに切り替えたそうだ。そのWebサイトに曰く（なぜかWebサイトのtitle要素がHomeになっていて、わけがわからないのでURLにした）

Jabirプロジェクトは2012年にMuhammadreza HaghiriとReza Bagherzadehによって設立された。このプロジェクトは初心者向けでデスクトップ志向のオペレーティングシステムを目的としている。その後、Muhammad Esmaeiliがプロジェクトに加入した。そもそも、JabirOSはUbuntuベースのオペレーティングシステムだった。2013年、我々はLinuxからBSDファミリーに移行することを決定した。JabirOSはFreeBSDのforkとなったのだ。

新JabirOSの機能：

• BSDベースOS
• インストールと利用が簡単
• あらゆるコンピューターに最適

つい先週、JabirOS 1.0.1がリリースされたらしい。

JabirOS 1.0.1 is released!

では早速、その初心者向けのインストール方法をみてみよう。

How to Install JabirOS (Page 1) / Desktop Usage / Jabir Project Community

JabirOSをインストールするには、まずダウンロードする。ダウンロードした後は、DVDに焼く。

• Liveモードでログイン

1. rootとして：ユーザー名に"root"、パスワードに"toor"を使う
2. 一般ユーザーとして：ユーザー名に"jabir"、パスワードに"jabir"を使う

• ハードディスクドライブのパーティションを区切る

デスクトップを右クリックして、ターミナルセクションからXTermを選ぶ。
Jabirユーザーとしてログインしたのならば、suと入力したあと、toorと入力してrootとしてログインする。

そして、ディスクのパーティションを区切る：(この例の場合、/dev/ada0)

# gpart create -s gpt /dev/ada0

# gpart add -s 64k -t freebsd-boot /dev/ada0
# gpart add -s 1g -t freebsd-swap /dev/ada0
# gpart add -t freebsd-ufs /dev/ada0

パーティションにいくつかの変更をする。

# gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 1 /dev/ada0
# newfs -U -j -L root /dev/ada0p3
# swapon /dev/ada0p2

ルートパーティションをマウントする。

# mount /dev/ada0p3 /mnt

マウントしたら、"jabirinstall"スクリプトを実行する。

# jabirinstall

展開された後、/mntディレクトリをchrootする。

# chroot /mnt /bin/csh

以下の変更をする。

# rmuser jabir
# passwd

タイムゾーンの設定をする。

ln -s /usr/share/zoneinfo/Asia/Tehran /etc/localtime

fstabの変更をする。

# nano /etc/fstab

このファイルの中身をすべて消す。

/dev/ada0p2    none   swap   sw 0 0
/dev/ada0p3      /        ufs    rw  1 1

設定

1. 自動的なネットワーク接続

# nano /etc/rc.conf

して、以下を追加

ifconfig_device="DHCP"

たとえば、この例のネットワークデバイスはem0だ。

• 終わり

このあとリブートする。リブートしたら、JabirOSをエンジョイできる。

いやーこんなにかんたんにびーえすでぃーべーすのおーえすをつかえるなんてぼくちんかんげきだなー。

ちなみに、初心者向けでデスクトップ志向を謳う割には、デフォルトではブラウザーとかの至極一般的なソフトウェアがインストールされないので、そのようなソフトウェアが必要な場合は、BSDではおなじみのpkg_addでインストールする必要がある。もちろんこれもコマンドラインインターフェースのツールだ。BSDユーザーは初心者でもターミナルとCLIツールを恐れないのだろう。

ちなみに、このOSの存在は、最近、すっかりこのブログのネタを拾う元となったphoronix.comで知ったのだが、なんとphoronix.comの該当記事のフォーラムに開発者のMuhammadreza Haghiriが現れている。

[Phoronix] JabirOS: A Former Ubuntu OS Turned FreeBSD
JabirOS: A Former Ubuntu OS Turned FreeBSD

なんでも、イランではすでに100人ぐらいのユーザーがいるのだとか。

[Phoronix] Samsung Properly Open-Sources exFAT File-System

少し前、邪悪なMicrosoftの特許汚染されたexFATをLinuxカーネルでネイティブにサポートするためのソースコードが、GitHub上で公開された。

問題は、そのソースコードは、邪悪なSamsungからの意図しないリークだったことだ。そのソースコードとは、邪悪なSamsungのプロプライエタリなタブレット製品で、exFATをサポートするために、バイナリブロブの形で配布されていたプログラムのソースコードだったのだ。

さらに問題をややこしくすることに、そのソースコードは、なんとLinuxカーネルのGPLシンボルを使っており、当然GPLで提供されるべきものだったのだ。つまり、いままで邪悪なSamsungはGPL違反を犯していたことになる。

この度、GPL違反を暴かれたSamsungは公式に該当のソースコードをGPL下で公開することにしたそうだ。まったく、問題が発覚するまで黙っているとは、純然たる悪意を感じる。

ところで、その正式にGPLで公開されたソースコードではあるが、どうもリーク版と比較すると、コメントが全て取り除かれているそうだ。邪悪なSamsungの自由ソフトウェアへの姿勢が如実に現れていて興味深い。そもそも、コメントを取り除くというのは、GPLに違反するのではないだろうか。

私には一切理解できないが、純粋なビット列で表現できるデータ構造であるはずのファイルシステムであるexFATに、アメリカ合衆国では特許性が認められているらしい。不思議なことだ。

体調は戻ったものの、クビを右に傾けると目が回る症状は、まだ治っていない。なぜかこの症状は再現性が謎だ。あるときは思いっきり首を回しても再現せず、かとおもえば、何気ないわずかな傾きで立っていられないほど目が回ることもある。

クーラーのせいかもしれぬというので、とりあえずクーラーを切ってみることにした。PCは、まあクーラー無しでもCPUやGPUの温度は許容範囲内のようだ。この前CPUクーラーが壊れた時に買った、巨大なCPUクーラーも一役買っているのだろう。念の為に、少し溜まっていたホコリも取り除いた。

さて、困ったものだ。

ふと、lispのような言語は、xkcd的には結構面白いネタになるんじゃないだろうか思い、xkcd.comを"lisp"で検索して、面白かった漫画をいくつか拾ってみた。

xkcd: Lisp

LISP

昨晩、LISPの本を読んでてうたた寝してしまった。
急に、一面真っ青な世界に誘われた。

その刹那、よく言われるように、大悟を得た。LISPコードのありのままの構造が手に取るように分かる。
「何と、carだらけだ」
パターンとメタパターンが踊り、文法は形を失い、その純粋にして真の意味の中を泳いだ。イデアが具現化したのだ。

嗚呼、神はこの言語を使って宇宙を創造なされたに違いない。

「いんや、違うよ」
「そうなの？」
「いやまぁ、使うにゃ使ったけどさ。大半はPerlでのやっつけ仕事さね」

神ですらやっつけ仕事にはPerlを使う。

xkcd: Lisp Cycles

LISPの歴史は繰り返す

LISPには半世紀以上もの歴史があるのに、いまだに似たような疑問を繰り返してる

この歴史は永遠に繰り返されるんじゃないかな。
新しい世代の少数のコーダーが、それぞれ独自にLISP技法を再発見するという、さ。

これがお前の親父さんの括弧だ。
立派な武器だ。
まだ・・・文化的だった時代のな。

最後のコマとtitleテキストはスターウォーズへのリファレンスとなっている。なお、最近スターウォーズをエピソード4とか称する改悪が行われているようだが、筆者はスペシャルエディションともども認めない。先に撃ったのはハンソロに決まっている。

xkcd: (

(

(閉じられていない括弧に出くわすと一日中不安にかられる

LISPがらみじゃないけれど検索結果に出てきた面白いxkcd

xkcd: Regular Expressions

xkcd: 正規表現

なにか新しい技術を学ぶたびに、その技術を使って人を救う妄想をしてしまう。

「まずい、殺人鬼が旅行に出かけた彼女を追いかけてるわ」

「でも見つけるには、200MBものメールの中から、住所のようなものを探しださなければならないわ」
「そんなの無理だ」

「みんな、下がっていろ」

「俺は正規表現を知っている」

正規表現で人を救おう。

xkcd: So Bad It's Worse

駄作すぎるのでなお駄作

ヒント：「クソ映画を観る夜」だったとしても、スターウォーズ　ホリデースペシャルだけはやめとけ。

MOVIE ENJOYABILITY：映画の楽しめる度
GOOD：良い
BAD：クソ
MOVIE QUALITY：映画の品質
GOOD MOVIE：良作
OKAY MOVIE：佳作
BAD MOVIE：駄作
SO-BAD-IT'S-GOOD：駄作すぎて逆に良作
STAR WARS HOLIDAY SPECIAL：スターウォーズ　ホリデースペシャル

スターウォーズ　ホリデースペシャルは、1978年にアメリカのテレビ局CBSで放送された、スターウォーズのスピンオフ作品。スターウォーズの主要な俳優はほとんど出演している豪華な内容なのだが、あまりにも伝説的に駄作過ぎたため、二度と再放送されることなく、またパッケージ化もされていない。ジョージ・ルーカスは製作に関わっていない。ジョージ・ルーカスに「俺に時間とハンマーがあれば、この世に存在するこの番組のすべての録画を見つけて、叩き潰したい」と言わしめている。

実際、ジョージ・ルーカスは、著作権法を使って、ハンマーで叩き潰すのと似たようなことをやっている。この伝説的な駄作は、1978年に一回放送されただけで、その時たまたま録画されたものが、オタク達の間でやり取りされてきた。誰でもやる気さえあれば観られるようになったのは、インターネットが普及して、個人の情報の流通コストが極めて低くなった、ごく最近のことだ。それも、著作権法上違法となる。今現在、ホリデースペシャルを合法的に観る方法は存在しない。titleテキストの、「あまりにも伝説的に駄作だから、オタク度を誇るためには、torrentして観なきゃならんと思ってる？　おれも、かつては、そう思ってたよ」からすると、おそらく、Randall Munroeは、bitorrentプロトコルを使って流通しているホリデースペシャルの複製物を入手して観たのだろう。いくら伝説的に駄作だといえ、「駄作過ぎて逆に良作」を期待して、あるいは己がオタクであることの証拠として、観たのだろう。その結果がたぶんこれだ。

なお、スペシャルエディション（特別版）とは別物だ。スペシャルエディションは、オジリナルのスターウォーズのフィルムをクリーンアップして、特殊効果を付け足し、解釈が曖昧な部分を理路判然とさせたと主張する蛇足的な復旧品で、駄作であることはもちろんだが、別物だ。

The Star Wars Holiday Special - Wikipedia, the free encyclopedia

xkcd: Python

Python

「お前飛んでるじゃないか、一体どうやって」
「Pythonさ」

「昨日の晩学んだんだが、もう物事が何でも単純に見えるね」
Hello worldは単に、
print "Hello, world!"

「いや、さっぱり分からん、動的型付け？　空白文字？」
「お前も来いよ。プログラミングがまた楽しくなるんだぜ。全く別の新世界がここにあるんだぜ」
「でもどうやって飛んでるんだ？」

単に、
import antigravity
とタイプしただけだよ。

「それだけ？」
「あと、医療薬品倉庫にあるのを全部試してみただけだよ」
「でも、これがPythonだと思うよ」

ちなみに、Python 3では、print文は廃止された。

Shebangとは、UNIXのシェルスクリプトの業界標準で、シェルスクリプトの一行目のコメントの、#!を意味する。sheが短母音か長母音か分からなかったので、英語ネイティブにたずねたところ、人によって意見が違う。短母音の方が多数派のようなので、一応シバンが近いものになるだろう。日本語版のWikipediaでも、シバンとしている。この機能には他にも多数の名前があるが、もっとも有名なのが、Shebangだそうだ。

その業界標準的な文法は、以下の通り（ただし、後述するように、この文字列の扱いについては違いがある）

#! 文字列 [改行]

普通、実行権限のついたファイルは、標準のシェルで実行されるが、このShebangがある場合は、#!から改行までの間の文字列を、後述するバラバラな方法で解釈して、execで実行し、その際の引数には元のシェルスクリプトファイルへのパスが指定される。

問題は、このshebangは、規格化されていない業界標準で、誰もが使うにも関わらず、まともにドキュメント化もされていないということだ。その実装には、かなりの差がある。

英語版Wikipediaに詳細な歴史的背景がまとめてある。

Shebangとは、Unix 7と8の間に付け加えられたらしい。同時期にBSDでも実装されている。Unix 8はプロプライエタリとなって一般には使われなくなったので、世間一般には、4.2BSDの実装がよく知られている。

このShebangという名前は、オリジナルの実装者であるデニス・リッチーの命名によるものではない。また、デニス・リッチーの身近にいたペットの名前でもないそうだ。どこかで自然発生したらしいが、初出は明らかになっていない。

問題は、この実装方法、特に#!から改行までの間の文字列の解釈方法に、実装ごとの差異が存在することだ。

あるOSは、#!から改行までの間の文字列を、インタプリターへのパスとみなし、そのまま丸ごとexecに渡して実行しようとする。これは、空白文字も合法なファイルパスであることを考えると、別段おかしくもない。また、shebangをサポートしていないOSもある。

そのようなOSは幸いにも絶滅したが、今ひとつ問題がある。

あるOSは、#!から最初の空白文字までの文字列をインタプリターへのパスとみなし、そのあとに続く空白文字で区切られた複数の文字列を、それぞれインタプリターに対する別々の引数として渡す。

#! インタプリターへのパス 引数1 引数2 引数3 ... [改行]

世の中の実装がみなこうであったなら、話は楽になるのだが、残念ながら別の実装がある。

あるOSは、#!から最初の空白文字までの文字列をインタープリターへのパスとみなし、最初の空白文字から改行までの文字列を、インタプリターへのひとつの引数として渡す。

#! インタプリターへのパス 引数 [改行]

つまり、以下のようなshebangの場合、

#! /usr/bin/interpreter -a -b -c

引数は"-a -b -c"ひとつとなる。これはインタプリターに複数の引数を渡したい場合、問題になる。

厄介なことに、この最後の実装方法は非常によく使われている。たとえば、有名なUNIX風OSの実装である、GNU/Linuxも、この実装を採用している。

多くのGNUのツールは、一文字オプションについて、-abcのようなまとめての指定をサポートしているが、それでは根本的な解決にならない。それに、インタプリター側での対応が必要だ。自分の環境ならば改変も可能だが、他人の環境で実行される場合は難しい。

引数の分割をする独自envもどきを書けば自分の環境では問題解決するが、やはり他人の環境で実行されるシェルスクリプトではそのような解決方法は取りにくい。

また、perlなどのインタプリターとして使われる一部のプログラムは、このようなshebangの実装への対処として、shebangを自分でも解釈して、引数として扱う実装になっている。ただし、そのような対処をしていないインタプリターの場合はどうしようもない。自分の環境ならば改変もできるが、他人の環境で実行されるスクリプトには使えない。

とはいっても、

Shebang (Unix) - Wikipedia, the free encyclopedia
shell - how to use multiple arguments with a shebang (i.e. #!)? - Stack Overflow

ところで、ドキュメント化されていない挙動といえば、GNU bashでは、

$ NAME=VALUE COMMAND

とすれば、あたかも

$ env NAME=VALUE COMMAND

とされたように動作するのだが、この挙動も、GNU bashのドキュメントには見当たらない。これには一体どういう歴史的経緯があるのだろうか。

Bourne-Again SHell manual - GNU Project - Free Software Foundation (FSF)

完全に3Dプリンターで出力した銃らしい。ひび割れるまでに、実弾（Winchester Dynapoint）を14発、発射できたそうだ。

形は銃。弾は銃身と銃床を分離した上で手で装填。薬莢の排出は細長い棒を使って押し出す。撃鉄（撃プラスチック？）を手で引いて、引き金（引きプラスチック？）を引くと、撃鉄が十分な力で動いて弾を叩くようだ。

今気がついたが、日本語だと、銃におけるハンマーとかトリガーが金属を意味する名前になっているのが面白い。撃鉄はともかく、トリガーはもはや、普通に製造されている中でも、プラスチックが使われているものもあると思うのだが。それから、今までストックという意味の銃床（じゅうしょう）の読みを知らなかった。

本当に全部3Dプリンターで印刷されているのだろうか。3Dプリンターで印刷可能なプラスチックだけで、ハンマーをどうやって十分な力で動かしているのか気になる。動画ではやはり力不足なのか、何度も失敗している。

これは日本では免許無く所有すると違法になるのだろうか。銃の定義というのが非常に気になる。実弾を発射する機能があれば銃になるのだろうか。とすれば、万力と金槌の組み合わせは銃だろうか。

米がなくなったので、まだすこし体がだるいが、ふらふらと近所の米屋まで、米を買いに行った。そう、米屋だ。この米屋は、まだ米が専売だった時代からの店だ。今日、ふとしたことから、この米屋の面白い話を聞いたので、忘れないうちに書いておく。

この米屋は、ホテルなどの大規模に米を必要とするところに米を卸す商売と、店頭での販売をしている。店頭での販売と言っても、今風の接客があるわけでもない。店には開閉するドアもなくシャッターがあるだけだ。シャッターを開けると巨大な米袋が大量に積んであり、精米や秤のような機械も所狭しと配置してある。

「商品」は、シャッターを開けたところの棚に、四袋だけ陳列してある。先客がいたのでなければ、常に四袋並んでいる。いかにも米屋風の、5kgの米袋に手で詰めて袋の口を縛った「商品」だ。

「商品」は、グレードに応じて値段が付けられている。といっても、価格差は大体200円刻みぐらいで、一番安い商品と、高い商品の差は800円ぐらいだ。米の品種は記載されていない。私は別に、まずくなければ米のブランドなどどうでもいいのだが、米の品種を書かないことは常々不思議に思っていた。以前、一番安いものと高いものを食べ比べてみたこともあるが、私には味の違いは分からなかった。

さて、この米屋には、二人の人間がいる。ひょろっとした愛想のいい主人と、太った店番だ。この店番は、実際には他にもなにかしているのかもしれないが、私は主人がいない間の店の番をしているところしかみたことがない。実際、この店番は主人のような職人魂は感じられない。ただのオッサンである。今日は、あいにくと主人が米の配達に出かけていて、店番が座っているだけだった。私はいつも通り、一番安いグレードの「商品」を買い、「私の貧弱な舌では味の違いが分からない」とおどけた。すると、この店番は、自分にも違いがわからないといった。これをきっかけに始まった話は、とても興味深かった。

話の内容はこうだ。この商品の中身は、主人がブレンドしている。だから品種表示はない。米というのは、季節や年によって品質が変わる。どうもこの主人は、年間を通じて、米の粘りと味が変わらないように、常に味を見て、品質を一定に調整する独自のブレンドをしているのだという。

品質を一定に保つためのブレンド！　そんなコーヒーやウイスキーのようなことを、米でやるとは！

なるほど、それで米の品種表示がないのは合点がいった。しかし、値段の差はどう説明するのか。

店番「それがよく分からんのです。単に高い米をたくさん使うとも限らないし。本人のこだわりとしか言いようがなくて」
私「なにか本気具合のようなものなんでしょうか」
店番「さあ？」

飲食業などに大量に卸す際にも、値段の範囲でブレンドして品質の調整を行なっているという。

店番「オレにはよく分からんこだわりでしてね。そんなことしなけりゃ余計な手間もかからないのに」

この米屋の店先は暑い。クーラーが設置されていないからだ。しかし、店の奥の米を保管する倉庫にはクーラーを設置し、常に涼しくしてあるのだという。ここはシャッターを開けた店先が作業場で、精米や計量などを行なっているのだが、今のような夏の暑い時期は、作業場である店先にはあまり米袋を出さないのだという。暑いと米が痛むからだ。米の保存は大事なのだ。

この米屋の店頭に、商品が四袋しか並べられていない理由も、米の品質のためだという。始めから作り置きしておけばいいのに、常に商品をグレード別に一袋づつ、四袋しか並べていない。もし、先客がある値段の商品を買っていって、補充の暇なく、その値段の商品を買う次の客が来た場合は、客を待たせてその場でブレンドをはじめる。私も何度かそのようにして買った。

店番「ふたつかみっつぐらいは作り置きしておけばいいのに、変なこだわりがあってやらないんです。それで余計に忙しくなってる」
私「素直に品種表示にしておけばそんな手間もかからないと思うのですが」
店番「まったくです。こだわりなんでしょう」

しかも、袋詰した商品が二日ほど売れない場合は、回収して詰め直すのだという。さらに、ギリギリまで精米を遅らせることもしていて、これも手間が増える一因になっているのだという。

そういえば、この店の主人は以前米を買った時、「これは新米だから少し柔らかいかもわからんで。柔らかいかなと思ったら水加減は少なめで」などと言っていたこともあった。まるで米の味を常に確認しているような口ぶりだったが、実際にそうだったとは。

すでに書いたように、この米屋には接客はない。米の作業所がたまたまそこで袋詰して売っているような店だ。私は店頭販売は趣味の領域ではないかと思っていたのだが、なんでも卸売だけでなく、店頭販売もそれなりに売れるのだという。このご主人のこだわりがあるからだろうか。

ただし、今風の接客はないが、昔風の接客ならある。この米屋の店先には、椅子が用意してあり、よく馴染みの客が座って他愛のない世間話をしている。いかにも伝統的な接客だ。

ちなみに、私がここ何年もこの米屋で買う理由は、味とか値段とかこだわりとは何の関係もない。家から近いことと、近所のチェーン店スーパーと価格差がないからである。味については分からない。

まあ、悪意をもって解釈すれば、クズ米の味をごまかすためのブレンドである可能性もあるわけだが。

そして、米トレーサビリティ法との兼ね合いもきになる。

農林水産省/米トレーサビリティ法の概要

しかし、この法律もけったいな名前だ。「トレーサビリティ」とカタカナで書いてもさっぱりわからない。むしろいさぎよくtraceabilityと書いたほうがマシだ。

以下の要素の参照は曖昧か - ここは匣

以下のコードは、gccとclangで解釈が異なる。

namespace NS
{
    template < int N >
    struct NS
    {
        constexpr static int value = N ;
    } ;
}

int main()
{
    using namespace NS ;
    NS<0>::value ;
    // gcc says a name 'NS' is ambiguous.
    // clang says 'NS' is class template name NS::NS ;
}

gccは名前NSを曖昧だとするが、clangは曖昧なくクラステンプレート名NS::NSだとする。

規格に照らし合わせると、おそらくclangの実装が正しく、gccの実装はバグであると思われる。3.4の冒頭に書いてあるように、

Name Lookupは、文法がその文脈上許す名前のみに行われる[3.4 Name lookup]。

たとえば、以下のようなコードを考える。

struct X { } ;
X X ; // #1、OK
X Y ; // #2、エラー、曖昧
struct X Z ; // #3、OK

int main()
{
    struct X X = ::X ; // #4、OK
}

#1の宣言文のName lookupに曖昧性はない。なぜならば、type specifierにXを使う時点では、まだ変数名Xは宣言されていないからだ。ただし、ある文脈で同じ名前のクラス名と変数名が同時に見える場合、のちの宣言文が少々厄介なことになる。

#2の名前Xは、Name lookupが曖昧となる。なぜならば、C++の宣言文にしっかりとした区別可能な文法ではないので、この文脈上では、変数名も現れることを許してしまう。そのため、name lookupはクラス名Xと変数名Xを見つけ出してしまい、曖昧となる。これを解決するには、Elaborated type specifierを使い、type specifierに現れるXはクラス名であると明示的に記述しなければならない。

#3には、曖昧性はない。なぜならば、この文脈では、Elaborated type specifierにより、文法の制約でXはクラス名でなければならないからだ。ここでは変数名は、文法上使えない。したがって、name lookupはクラス名しか発見せず、曖昧ではなくなる。

#4には、曖昧性はない。まず、Elaborated type specifierにより、最初のXは、文法上クラス名でなければならない。そのため、曖昧性はない。次のXは、関数のブロックスコープ内で名前を宣言している。これは外側のグローバル名前空間スコープの名前Xを隠すが、これ自体には問題はない。内側のスコープが外側のスコープの名前を隠すというのは、C++ではよく使われることだ。最後の初期化式に使われているXは、スコープ解決演算子により、グローバル名前空間の名前であることを明示的に指定している。そのため、文法上、この宣言文の中で宣言したばかりの関数のブロックスコープの変数名はlookupされない。また、文法上、クラス名をここに使うことはできないので、グローバル名前空間スコープの変数名Xだけが発見される。そのため、ここでも曖昧性はない。

このように、C++では、name lookupは、その文脈で、文法上許される名前からしか探されない。

これを元に最初のコードを読む。using directiveにより、main関数のブロックスコープ内では、'NS'という名前に対して、名前空間名NSと、クラステンプレート名NS::NSが同時に存在する。ただし、NS<0>::valueという文脈では、名前空間名は、文法上使えない。C++には名前空間テンプレートはないし、名前空間には比較演算子を適用できないからだ。

そのため、これはgccのバグであろう。

4日の朝、どうもうまく起き上がれないと思いながら無理やり起き上がってみると、体調がひどく悪いことに気がついた。

首をわずかにでも右に曲げると、立っていられないほど目が回る。横になっていると首が微妙に動いてしまうので、仕方なく椅子に座ることにした。頭痛はないようだ。気がつけば、腹も痛いし吐き気がする。下痢ではないようだ。熱もないようだ。

とにかく、首を少しでも動かすと、気を失いそうなほど目が回る。椅子に座ったまま何もできず一日過ごす。

夕方、立っているのも辛いほど目を回しながら、水のような粥を作る。うまい。この世界にこれほどうまいものが存在したのかと感動するほどうまい。

5日朝、どうやら正露丸は効いたようだ。腹はだいぶまともになった。しかしまだ薄い粥がうまい。だいぶマシになったが、まだ首を右に曲げると目が回る。それから頭が痛い。熱も少しあるようだ。

5日夜、だいぶ良くなったので、記録がてらこれを書いている。。と同時に、薄い粥がそれほどうまく感じなくなってしまった。なにか噛みごたえのあるものが食べたい。しかし、今家にあるのは米ばかり。まだ少し目が回るので、歩くのは難しい。やれやれ。

昔から、どうも不衛生な生活をしているわけでもないのに、前触れなく体調が劇的に悪くなり、数日ほど悩まされた挙句、何でもなかったかのように回復する。どうもこの体はあまり丈夫ではない。歳をとっても変わらないので、なんだか自分は長生きできないのではないかと思う。

そして体調を崩した時に食べる、塩で味付けしたとても薄い粥（米に対して15倍ほどの水）のうまさは格別だ。もうこれからはメシは粥だけでいいと思うほどうまく感じる。残念ながら、体調が良くなると、そんな重湯のような薄い粥は、あまりうまいとは思わなくなってしまう。

ただ、今回の件に関しては、3日に食べたカレーが怪しい。思えば、この暑い中、作った後室温で5,6時間は放置してしまったような気がする。

flex - How can I pass the string "Null" through WSDL (SOAP) from AS3 to ColdFusion web service without receiving a "missing parameter error"? - Stack Overflow

stackoverflowで、

「"Null"という文字列をAS3のWSDL(SOAP)からColdFusion Webサービスに、"missing parameter error"というエラーを出さずに渡すにはどうすればいい？」

という質問が注目を集めていた。

はて、この問題はどこかで見た気がする。

xkcd: Exploits of a Mom

「もしもし、あなたの息子さんの学校です。うちの学校がコンピューターシステムのトラブルに見舞われまして」

「あらまぁ、うちの子が何か壊しまして？」
「ある意味・・・」

「あなたの息子さんの名前は本当に、Robert'); DROP TABLE Students; -- なのですか？」
「ええ、そうですわ。うちではLittle Bobby Tablesちゃんって呼んでますの。」

「えーと、うちの学校は本年度の生徒の記録を全部失いました。ご満足いただけましたか？」
「あなたも入力をサニタイズする重要性に気がついたなら嬉しいのだけれどね」

その解決方法として提案されている一つが、このxkcdへのリファレンスで面白い。

AS3に以下のコードを追加

if(lastname == 'null') lastname = 'Little Bobby Tables';

ColdFusionに以下を

if(lastname =='Little Bobby Tables') lastname = 'null';

問題は全て解決。

// これはwork-aroundである. ドキュメントを参照されたし: xkcd.com/327

「おいグレッグ君。きみはNullさんの問題の修正を実装してくれたよね。あんがとさん。ところで、新しい社員のLittle Bobby Tablesさんにも何故か問題があるんだけど、修正できるかな？」

このstackoverflowの質問は、最近注目を集めたらしく、Hacker Newsでも議論されているが、そのコメントに興味深いものがある。

We have an employee whose last name is Null. He kills our employee lookup (2012) | Hacker News
A Japanese company once made the decision that they needed "virtual" employees i... | Hacker News

日本のとある会社は、あるシステムに、架空の社員が必要であるとの決定を下した。例えば、組織図に、まだその役職につく人が決まっていない時に、役職を加えるだとか、その他多数の目的のためだ。そこで彼らは賢いアイディアを思いついた。「おい、これが必要なら、俺らは単に、XX_JOB_REQUESTとかXX_INCOMING_TRANSFERみたいな状態フラグの一種として「日本語の名前」[訳注：後のコメントで補足しているがローマ字]を入力すればいいんじゃね？」

この会社のある開発者が、新しい状態フラグを追加するたびにシステムを変更しなければならないことに嫌気が差し、書いたコードが、大体以下のようなものだった。

  if (InternalStringUtils.isAllLatinCharacters(employee.getJapaneseName()) {
    /* この「社員」には給料を支払う必要がないので、
    給与振込の社員情報取得のバッチリストからは除去する */
    ...

なぜ私がこの興味深い実装の選択について知っているか、言う必要はあるかね？

他にも、中国の社員管理とか銀行とかのシステムは全部中国語で入力する前提で作られているので、ラテンアルファベットを入力すると大抵動かないとか、苗字に空白文字が入っている人の喜劇などが報告されていて興味深い。

'Compilers in OpenBSD' - MARC

List: openbsd-misc
Subject: Compilers in OpenBSD
From: Miod Vallat <miod () online ! fr>
Date: 2013-07-31 21:19:11
Message-ID: 20130731211911.GE17582 () tazenat ! gentiane ! org

最近の議論(Default software in the base)は、近い将来、OpenBSDではClang/LLVMをシステムコンパイラーとして使う方向になっている。この議論は、これ以上発展していないが、現在OpenBSDのデファクトなコンパイラーメンテナーである私が思考の帯域を浪費してみようと思う。

だいたい、私はOpenBSDのシステムコンパイラーの保守に立候補したわけじゃないのだ。私は移植メンテナーのひとりとして、gccの大量のバグを修正するか回避するかしなければならなかったので、自然にこの地位に至ったのだ。私はその必要がなければよかったのにと思っているのだ。

今は昔、*BSDプロジェクトが始まってからの数年、様々なプラットフォームのBSDシステムが使っていた自由ソフトウェアコンパイラーはgccだった。pccは開発が停止し、TenDRAはいまだ面倒なビルドシステムを使っていて、十分なプラットフォームをサポートしていなかった。これが当時の自由ソフトウェアの地のすべてだったのだ。

さらに、gcc 2.5（当時）は、いくつかのバグを抱えていたが、それほど大量というわけではなかった。gcc 2.5はどの最適化レベルでも、動くコードを生成することに関して信頼することができ、何も深く考える必要はなかったのだ。つまり、当時はコンパイラーを保守する必要などまったくなかったのだ。なぜなら、gcc 2.5は（ほぼ）バグフリーだったからだ。

この状況は、2.7の時代まで続いた。この当時の知識としては、-O2には-fno-strength-reduceを組み合わせて使えというものだ。なぜならば、2.7はstrength reductionコードにバグがあり、i386コードに影響したからだ。これさえ守れば、当時のコンパイラーは信頼できた。

そして、C++98や、C99といったものが出てきて、gccにとっては多大な作業となった。これらの規格の新機能をサポートすることのみを試みていればの話だが。中には当時の思想を覚えている人もいるだろう。保守的だが、C++98に追いつこうとしていたgcc 2.8と、最適化コードを拡充して、より速いコードを生成しようとしていた"Pentium gcc"一味だ。

このプロジェクト達は、最終的に、gcc 2.95としてマージされた。その時から、いくつかのことが永久に変わってしまったのだ。

• より多くの人間が、[訳注：特定プラットフォーム]専用の最適化に関わるようになった
• これらの最適化は、2.5/2.7の最適化とは違い、「ほぼプラットフォーム非依存」ではなくなり、かわりに特定のターゲットプラットフォームの機能を活用するようになり、より多くのコードが、ある最適化手法を適用すべきかどうかの判断をするようになった

これによる不可避な結果として、世界のある重要な仕組みが変わってしまった。gccにはバグが存在するようになり、その事実を受け入れ、対処しなければならなくなったのだ。

筆者が"gcc"と書く時、読者は「コンパイラー」と読んで差し支えない。アーサー・C・クラークがかつて言ったように、「十分に最適化するコンパイラーは魔法と区別がつかない」

この昔話は我々に何を教えてくれるのか。

一つ目に、コンパイラーは壊れているということだ。モダンなコンパイラーには最低限の正確性と信頼性を期待したいところだが、期待できない。どのコンパイラーでも状況は同じだ。

二つ目に、コンパイラーは変化するものだということだ。十分なテスターと開発者のいないアーキテクチャーは、挙動がおかしくなり始め、（なぜならば、新しく付け加えられた最適化手法における推定をぶち壊しているにもかかわらず、95%は正しく動くコードを生成するからだ）、そしていずれ、取り除かれる。この典型的な例はm88kだ。m88kは、ターゲット専用のマクロが急に括弧で囲まれた引数を必要とするようになり、そして誰もm88kなんてテストしないし気にかけなかったので修正されず、gcc 2.95で壊れた。

OpenBSDが、プラットフォーム毎に別のコンパイラーを使うのはそのためだ。あるgccのリリースは、あるあまり有名ではないプラットフォームには適切ではないかもしれないからだ。（これはgccにおいては驚くにあたらない。というのも、他のコンパイラーとのベンチマーク競争にあけくれているし、gcc 3からは、gcc開発者は「バグフリー」な新バージョンをリリースしようとして、"regression"のみを修正するポリシーを持っているものの、あるいは、より多くの時間をregressionの定義を変更することに費やしているか、あるいは、あるregressionは実はregressionではないと説明し、stableリリースで修正する必要を生じさせないように努力しているからだ）。gcc 2.95がC99を完全に実装していなかったのは実に残念なことだ。もし実装していれば、我々は喜んでgcc 2.95を、現在はサポートされていない古いプラットフォーム向けに保存し、新バージョンを罵ることもできたであろうに（何も変わらないが）

gccからclangに切り替えるのは検討すべき価値があるし、実際、何人かの開発者が実験している。おそらくいくつかのプラットフォームでは移行されるかもしれない（llvmはOpenBSDほど多くのプラットフォームをサポートしていないため）。しかし、OpenBSDのサポートするプラットフォームの一部で切り替えるのは、単純な作業ではなく、多大な労力を必要とする（例えばlibgccをcompiler-rtで置き換えるとか、欠けているプラットフォーム向けに移植するとか）

そして、もしそのような切り替えが起こったならば、バグが発見され、問題を修正しなければならなくなる。我々はllvm開発者が、gcc開発者よりも、バグ報告とバグ修正をより良く行うと楽観視することはできない（ただし我々はそう願っているが）

upstream開発者による修正がなければ、我々の手で出くわすコンパイラーの問題を解決しなければならない。時には、upstreamに提出するパッチを選ぶだけでよく、我々が使うバージョンにbackportする必要がないこともあるが、時として、最新版のコンパイラーでは再現しない問題もあり、そういう場合は我々の開発者のスキルとコンパイラーの修正能力に頼らなければならないのだ。

うちのところの開発者の何人かは、長年の成果で、gccを恐れなくなり、問題を調査し、修正をbackportし、また修正し、あるいはバグを迂回したりできる。私は今ここでは、niklas@とespie@とetoh@とotto@しか挙げないが、名前を挙げられなかったその他の者は許してもらいたい。これは、少なくとも、簡単な道のりではない。さて、また、うちのところの何人かの開発者は、llvmにおいて似たような知識を構築中だ。彼らに多大な幸運あれかしと願うし、私も近い将来、彼らに合流する。

とはいえ、最も有名なOpenBSDプラットフォームをgccからllvmに置き換えることには、あまり自信が持てない。

数ヶ月か数年たてば、また状況は違ってくるのだろうが。

・・・しかし、それ以外に起こってほしいことがある。

オープンソースコンパイラーのLTSリリースだ。

今日のすべてのコンパイラーがバグまみれで、多くのバグが、ちょっと単純ではないコード辺をコンパイルしただけで出くわすわけで、しかも我々はアセンブリに戻るなどということはできない、我々には信頼できるコンパイラーが必要なのだ。

GCCとLLVMは、Fortune 500に入る会社に支援され、賢い開発者にフルタイムで働かせるべく賃金を払っている。

しかし、長期サポート版を提供しようという者は皆無だ。バージョンNのバグはバージョンN+1で修正されるが、新しいバグが導入される。少し落ち着いて信頼できるコンパイラーを作ろうという者はどこにもいない（なぜならば、バージョンN+1はどっかの非現実的なベンチマークで3.14%速いからだ）。まあまあ、そんなことを気にする必要はありません。明日のコンパイラーは無限ループを5秒以内に完了できるコードを吐くかもしれませんよ。さらなる発展をお見逃しなく！

自由ソフトウェアの世界は、LTSコンパイラーを必要としている。最後のデファクトLTSコンパイラーはgcc 2.7.2.1で、これはモダンなCやC++のコードをコンパイルできないほど古い。

自由ソフトウェアのLTSコンパイラーが現れたならば（gcc forkにせよ、llvm forkにせよ、別のものにせよ）、OpenBSDは、とても真剣に、利用を考慮すべきだ。我々だけがそれを行う自由ソフトウェアプロジェクトというわけではないだろう。

Miod Vallatが"Pentium gcc"と呼んでいるのは、gcc 2.7から2.8あたりの時代に発生したgccの多数のforkのことだ。とくに、Cygunusやegcsのようなものは知名度が高い。

まだストールマンがGCCの開発姿勢に強い影響力を持っていた時代、GCCはかなり保守的な伽藍式の開発をしていた。外からの大規模な新機能追加パッチは、ほとんど受け付けなかった。GCCの開発自体、停滞気味だった。そこで、GCCのforkが多数立ち上がり、特に多くのforkで、プラットフォーム専用の最適化に力が注がれた。

結局、GCC本体の開発は止まり、EGCSをGNUに取り込むというか、公認するという形で、GCC 2.95がリリースされ、今のGCCの本流となっている。GCCとEGCSのマージと言うよりは、EGCSに母屋を明け渡したような感じだ。

ストールマンが強い影響力を持っていた保守時代、GCCは最適化の具合はともかく正しく動くコードを吐いたが、今のGCCはバグまみれというのは、なかなか考えさせられるものがある。

今ではClangもでてきて、自由なソフトウェアのCやC++のコンパイラーはGCCの独壇場ではなくなったが、正しく動くコードを吐くという点に関しては、どちらも大差なく悪いのだとか。

コンパイラーの世界では、信頼できるLTSリリースは存在しない。やはり、コンパイラーとして評価されるには、優秀な最適化により、競合のコンパイラーより優れたコードを生成しなければならないし、正しいコードを吐くというのは、どうも二の次のようだ。それに、正しいコードを吐くという修正だけbackportするというのも、相当の手間なのか行われていない。

もとより、コンパイラーのbackportというのがあまり一般的ではないと思う。backportすべき修正があまりにも多くなるのも問題なのだろうか。結局、問題を修正するには、バージョンN+1でなければならず、それには新たなバグも含まれる可能性がある。

Ex-Employer, Not Secret Spying, Triggered Police Inquiry of 'Pressure Cooker' Search | Threat Level | Wired.com

アメリカで「圧力鍋」と「リュックサック」という検索クエリーでGoogleで検索した人間が警察の捜査を受けたというニュースがある。どうやら、警察がGoogleの検索クエリーを無差別に傍聴しているのではなく、昔の職場のコンピューターで検索した履歴を、雇用者が見つけ、警察に通報、警察が通報を受けて捜査ということらしい。

いくら圧力鍋とリュックサックを使った爆破事件が最近あったからといって、そのようなキーワードを使用した人間を捜査するというのも馬鹿馬鹿しい話だ。まあ、いたずらにSWATを送るという意味のswatingという言葉まであるアメリカらしいお国柄と言えるのだろうか。

それはさておき、以前、xkcd.comのRandall Munroeが、what-ifで圧力鍋で行える最も危険な行為について考察していた。

Pressure Cooker

それによると、圧力鍋で行える最も危険な行為は以下のようなものである。

圧力鍋を5PSI(訳注：約34KPa)の酸素で満たし、安全弁から漏れだすまでフッ素を送り込む。700℃（これは℃であって°Fではない。もちろん、これは火災警報器を鳴らすであろう）に達するまで火にかける。そして、熱せられた蒸気を液体酸素で冷却されたステンレス鋼の表面に送り込む。

この手順はやや難しいが、正しく行えば、蒸気は二フッ化二酸素（O2F2）になる。

二フッ化二酸素の危険性については、検索してもあまり見つからない。この理由は、二フッ化二酸素は現在まともな利用例がなく、実験で作られるだけであり、その実験も、稀にしか行われないからのようだ。また、まともな化学者は名前を聞いただけで震え上がるようだ。

What ifでも言及している、化学者のブログIn the Pipelineで、O2F2について書かれている。タイトルは、「俺が絶対にかかわらないもの：二フッ化二酸素」

Things I Won't Work With: Dioxygen Difluoride. In the Pipeline:

最新版の俺が絶対に扱いたくない化学物質リストの改定は、フッ素科学の素晴らしき世界へと我々を誘う。私はこの分野で如何に研究がなされてきたか、一番初めに行われた研究がどのくらい昔なのか、いかに多くの危険で厄介な化合物が注意深く研究されてきたかを思うと、唖然とせずにはいられない。今日の研究の礎となった記念すべき実験がこれだ。

加熱器は約700℃まで熱せられた。部屋の照明を落とせば、加熱器のレンガが鈍く赤い光を放っているのが観測できる。タンクは300トルの酸素で満たされている。そして、全体の圧力が901トルになるまでフッ素が加えられ・・・

その通りだ。これから次に行うことは、まさしく読者が予想していることだ。酸素とフッ素を混合物を700度に加熱されたレンガに注ぐのだ。「おいよせ、やめろ」というのが、これに対するほとんどの化学者の反応だろう。「少なくとも俺が1マイルは離れてから、いや、風向き次第では2マイルだな」。これが、読者諸君、二フッ化二酸素を作り出す準備であり、文学的にはしばしば、FOOFの発生手順と呼ばれている。

まあ、「しばしば」というのは、相対的なものだ。これに関するほとんどのものは、単に考察している者たちであり、実際に作り出す者ではない。Rarely does an abstract that mentions density function theory ever lead to a paper featuring machine-shop diagrams, and so it is here. Once you strip away all the "calculated geometry of. . ." underbrush from the reference list, you're left with a much smaller core of experimental papers.[訳注:意味不明]。

実にハードコアだと言える。これは1932年のドイツで、RuffとMenzelによって準備された。彼らは愛すべきバカであった。というのも、これは何もフッ素について注意されていなかった時代ではないのだ。そもそも、フッ素はまだ単離される以前から注意されてきた。単離作業は1800年代に優に50年かかった。（単離にあたって、爆発したり中毒した人間の一覧は実に興味深い）。しかもこれは室温である。恐ろしげな700度では、フッ素は単原子ラジカルになり、その紳士的で慈悲深い性質を失う。しかし、この世で最悪の生産物を作るために酸素と反応させるというのは、つまりはそういうことだ。

FOOFは低温度下でしか安定しない。このようなものはとてつもなく細かくしないとRTにできない。筆者はこれを後の利用のために、90ケルビン下で個体にして保管した例を一件だけ知っている。しかしその論文、テンプル大学のA. G. Strengによる1962年の実験は、様々な点で深刻に危険である。Strengは二フッ化二酸素を複数生成して保管しただけでなく、様々な物質との反応を確かめる実験をしていたのだ。あらゆる物質だ。ひとつひとつ確かめていった。

「高エネルギー酸化剤である二フッ化二酸素は、有機化合物と強く反応する、たとえその融点に近い温度であったとしてもだ。固体エチルアルコールと瞬時に反応し、青い炎と爆発を生じる。O2F2の一滴が90°Kに冷やされた液体メタンに加えられたならば、...、白い炎が瞬時に生じ、燃焼するに従って青く変じる。0.2(mL)の液体O2F2が0.5(mL)の90°Kの液体CH4に加えられたならば、激しい爆発が起こる。」

しかもこれはウォーミングアップにすぎないのだ。もし、ウォーミングアップという言葉が、物質を-180℃（もし読者が台所用の温度計しか持ち合わせていないのであれば、これは華氏-300度にあたる）で起爆させるということに使っていいのならの話だが。多くのStrengの反応実験は、二度と実験されることはないだろう。論文はさらに、FOOFを、読者は反応させないだろうあらゆるものと反応させることについて続けている。アンモニア（「激しい」、100Kにおいて）、水の氷（爆発、自然に）、塩素（「激しい爆発」、そのため、彼は二度目にはもっとゆっくりと加えることにした）、赤リン（あまりよくない）、フッ化臭素、三フッ化塩素（なんだと？）、過塩素酸フッ素（！）、四フッ化二窒素（ありえん）、さらに続く。もしこの論文が文法的にまともで、JACSから発行されているのでなければ、狂人の所為だとみなすだろう。私は二ページ目に達した時点でうめき声を上げた。読者諸君、A. G. Streng、こいつは腐食性爆発ケーキすら食えるぜ。俺のアスベストチタン帽も脱帽だ。

Strengですら、予定していた実験のうちのいくつかはあきらめなければならなかった（bonus dormitat Strengus?[訳注：ラテン語、意味は、「良きStrengすらかぶりをふるのか？」、元ネタはホラティウスのArs poeticaに出てくる、 indignor quandoque bonus dormitat Homerus（良きホメロスすらかぶりをふるのはうんざりだ）]）。硫黄化合物は、その温度差が激しすぎるため、彼ですら負けた。例えば、硫化水素はFOOFの分子4つと反応して、六フッ化硫黄と、HF分子ふたつと、酸素4つと、433キロカロリーを生じる。この発熱は、誰でも絶対に何が何でも避けたい反応だろう。FOOFと硫黄との化学はまだ未開拓であるので、サタンのキムチを料理したければ、やるといい。

追記：これはモルあたり433キロカロリーであって、分子あたりではない（分子あたりは、核分裂や核融合でも不可能である。こちらを参照）。化学者はほぼ常にモル単位のエネルギーを考えるので、混乱が生じた。それでも馬鹿でかいエネルギーではあるし、読者はこのような反応を引き起こしたくはないだろう。

さて、誰か二フッ化二酸素を何かに使っているのか？　筆者の知る限り存在しない。この物質に対する最近の研究のほとんどは、ロス・アラモスの研究グループの手により行われていて、プルトニウムとか六フッ化ネプツニウムとかの国防物質の準備に使われている。しかし、この構造物をSciFinderで検索すると、予期せぬことに、商用販売しているところがあるそうだ。それはHangzhou Sage Chemical社である。この会社は、100g, 500g, 1キロの単位で販売しているそうだ。これは実に興味深いことだ。というのも、筆者は1キロの二フッ化二酸素はいまだかつて存在したことがないと思うからだ。誰か電話して、無料配達を頼んでみるべきじゃないだろうか。もし彼らが無料配達を断ったら、Amazonもこれを売っていると告げるべきだろう。お客様へのサービスは大事にしろよ。マヌケめ。

どうやら、二フッ化二酸素というのは、-180℃でほとんどの有機化合物を発火させることができるほど凶悪なシロモノらしい。