Island Life

< 「とりあえずやってみる」のスケーラビリティ | 教養の効用 >

2011/02/11

2147483647

少し前に英語の元記事がHacker Newsあたりに出てたような気がするけど、日本語でも紹介されててブクマを集めていた。

2^32-1が2147483647なので、どっかの怠け者のプログラマが32bit符号つき整数で 電話番号を保存したんじゃないか、というのが元記事の仮説。それより大きな電話番号を 入れようとしたら最大値でクリップされると。

実際この番号で検索すると、この番号を使っているビジネスが確かに出てくる。 テキサス州ダラスの番号のはずなのにニュージャージーだったりフロリダだったり。

でも、「電話番号に32bit符号つき整数を使った」という仮説はかなり疑わしいと思う。

USのエリアコードは201から始まり、900番台の終わりの方まで使われている。32bit符号つき整数をそのまま使った場合、全体の数%しかカバーできない。

たまたまスクリプトを書いたプログラマが、カバーできる領域に住んでいて、他の領域のことを考えていなかったのだろうか。 けれども、USのエリアコードは日本ほど綺麗に整理されておらず、新たなエリアコードが必要となる度に開いてるやつを使うものだから、隣接する区域で番号がとびとびになる。同じテキサス州ダラスでもメトロエリアは469であり、これは32bit符号無し整数にも収まらない。 US本土の都市部に住んでいれば近所でエリアコードがとびとびになるのは常識で、 201〜214だけサポートできればいいや、という考えはちょっと無理がある。

例外は人口が少ない州で、例えばハワイは全州808だ (なのでハワイで電話番号を 伝えたり記入したりするときにはエリアコードを書かないことが多い)。 201〜214の範囲でそういう例を探すと、207がメイン州全域、 208がアイダホ州全域、このあたりの住人が、自分の州のことだけ考えて スクリプトを書いたって説は辛うじてあり得るかもしれない。

でも、それよりは、 事務の人がPCの簡易データベースソフトか表計算ソフトか何かで住所録を管理していて、 カラムの型が意図せずlong intになってるのに気づかず 電話番号をタイプしたとかそういう話だったりしないだろうか。 つまり、最初から電話番号を入れるとわかっていて32bit intフィールドを使ったのではなく、 32bit intなフィールドに意図せず電話番号が入れられたのではないか、ということ。

そういう制限のあるソフトが実際にあるかどうか (そしてオーバーフロー時に最大値でクリップするかどうか) 手元では確かめられないんで、これも推測の域を出るものではないが…

Tags: 生活, Programming

Post a comment

Name: