バイナリエディタを作りました！

バイナリエディタを作りました。

インストールは

go get -u github.com/itchyny/bed/cmd/bed

でできると思います。

なぜ作ったのか

私は昔からファイルフォーマットに興味があり、画像ファイルやPDFファイルのフォーマットを調べるのが好きでした。 最近も圧縮ファイルのフォーマットを趣味で調べたりしています。 コンパイラ技術にも興味があり、ゆくゆくは実行ファイルを生成したりしたいなという思いもあります。

バイナリファイルをエディットするにはバイナリエディタが必要となるわけですが、自分の手に馴染むUIを持つエディタがありませんでした。 私は実はVimというエディタが好きなので、Vimのようなインターフェースを持ち、ターミナルの中で動くエディタを探したのですが、なかなかありません。 bviはかなりイメージに近く、かなり参考にさせていただきましたが、画面分割がないことやキーマッピングの挙動など細かいことが気になりました。 歴史あるソフトウェアなので敬意は抱いていますが、それは同時に自分で書き直したくなるのに十分な理由でした。

いつかはテキストエディタを自分で作ってみたいという思いがありますが、自分のワークフローが依存しているものが大きくて、なかなか実装し始めるまでのハードルが高いと感じています。 特にシンタックスハイライトなどの既存の資産をどう取り込むか、あるいは自前で実装するかといったことは悩ましい課題です。

一方で、バイナリエディタを作るのはとても簡単です。 テキストエディタよりも難しい点といえば、ファイル全体を読み込むのはよくなくて、例えば16GiBくらいの大きなファイルも読み書きできる必要はありますが、逆にここさえクリアしてしまえば、後は地道にUIを作るだけとなります。 少なくとも、ファイル構造を解析したり逆アセンブラ機能を作るまではそんなに難しくありません (まだこれは実装していないのでどれくらい難しいかはわかりません)。

最後に、自分の力を試したいという思いがありました。 UIを持つcliツールを作るのはよい勉強になります。 実際、いかにコアロジックとUI部分を疎結合に実装するか、端末への描画部分の実装、分割ウィンドウの管理やundo/redoの実装など、様々なことを学ぶことができました。

実装や学んだことと考えたこと

今回バイナリエディタを実装するにあたって学んだことや考えたことを書いておきます。

バッファの表現

バイナリエディタは、メモリーに乗らないような大きなファイルを高速に読み込んで表示する必要があります。 ファイルの内容は、部分的に読みながら表示しなくてはいけません。 画面はユーザーが上下にスクロールしたりいきなり最後に飛んだりします。 こういう時には、ファイルポインタを特定の位置に移動する lseek がとても重要です。 現在の表示領域からファイルの絶対位置を計算して lseek し、必要な分だけ read して表示すれば終わりです。

エディタとしては、任意の場所に書き込めなくてはなりません。 一部を消して保存したいこともあるでしょう。 これらの操作をできるように、 bed の実装ではどの範囲はファイルで、どの範囲は入力されたバイト列かを保持するようにしています。 コードで示すと次のような感じです。

type Buffer struct {
    rrs   []readerRange
    index int64
}

type readerRange struct {
    r    io.ReadSeeker
    min  int64
    max  int64
    diff int64
}

バイト列をファイルポインタと同じように Read と Seek できるようにしておき、ファイルから読む範囲とバイト列から読む範囲を同じように扱えるようにしておきます。 diff によって、エディタから見えるオフセットとファイルのオフセットの差を保持しておきます。 範囲の境界がわかればよいので max だけあれば十分ですが、両方持たせたほうが様々なコードが書きやすいので上記のように実装しています。

例えば1バイト挿入する場合、 readerRange を前後に分割して後ろの diff を一つ減らし、間にバイト列の readerRange を挿し込むのです。 削除する時もやはり前後に分割し、後ろの diff を増やしたり、範囲の境界を表す min や max を減らしたりすれば実装できます。

ファイルポインタや入力されたバイト列を完全に管理するのは少し大変です。 しかし、これらをきちんと実装しさえすれば、編集した部分だけ他の色をつけて表示したり、別々の巨大なファイルを結合したり、大きなファイルを半分に割って前後を入れ替えるのも容易に実装できます。 また、undo/redoも Buffer ごと保存していけば難しくありません。

なお bed ではスレッドセーフのために、 pread 相当 (Go言語のReadAt interface) を用いており、上記の io.ReadSeeker の部分は io.ReaderAt と io.Seeker をあわせた独自の interface によって実装しています。 なので、上記で lseek が大事だよと書きましたが、実はファイルの内容を読み込むという用途では使われていません *1。 Seek して Read するという操作はスレッドセーフではないため、ファイル先頭からの絶対位置を指定して (whenceがio.SeekStart) 読み込みたい場合は ReadAt を用いるほうがよいと思います。

[試して理解]Linuxのしくみ ~実験と図解で学ぶOSとハードウェアの基礎知識

いい本です

レイアウト分割

bed は Vim と同じようにウィンドウを分割することができます。

これは二分木のような構造体で実装されています。

type Horizontal struct {
    Top    Layout
    Bottom Layout
}

type Vertical struct {
    Left   Layout
    Right  Layout
}

type Window struct {
    Index  int
    Active bool
}

木構造の葉が Window となります。 分割を行う場合は、 Active な Window を Horizontal または Vertical で置き換えます。 これは、再帰的なアルゴリズムで実装できます。 bed の実装では、上記に加えてウィンドウの絶対位置やサイズも保持しており、描画時に利用しています。

なお、この二分木によるレイアウト分割は四畳半分割できないことが知られていますが *2、実用上は問題ないと判断しました。

パッケージ間の依存関係

エディタのコアロジックは、表示ロジックに依存させたくないし、直接触れないようにしたい。 この思いは、エディタの構想を始めた当初からありました。 実装はまだしていませんが、webインターフェースも実装し、ウェブブラウザでバイナリファイルを操作できても面白そうだと考えています。 bedコマンドの実装では、表示部分を簡単に差し替えられるようにしています *3。

依存関係逆転の原則、抽象に依存させよという考え方は、とても重要だと思います。 レイヤーごとの実装して木構造のように依存させていくのは、一見「きれいな依存関係」に見えますが、モノリシックで下の実装を差し替えにくく、テストもしにくく、またどちらのレイヤーに書くべきかの判断を誤りがちです。 このことに気がつくのに何年もかかってしまいました。

bed の Editor というメインの構造体は、ウィンドウを管理する Manager、コマンドラインインターフェースや補完を管理する Cmdline そして表示とキー入力のための UI に依存していますが、これらは全て interface にしています。 パッケージ間の依存関係を絶ち、コマンドの実装部分で注入しました *4。 これにより、実装の大きなパッケージがお互いに依存することなく、独立して実装を進めることができました。 コマンドラインの実装は、補完やコマンドのparseなど複雑になりがちで、うっかりメインロジックと結合していたら大変なことになっていたと思います。

パッケージ間の依存関係を描画すると次のようになります *5。

editorパッケージはwindow, cmdline, tuiパッケージに対して依存関係がありません。 bufferというエディタを支えるバッファを実装したパッケージも、コアロジックであるeditorから依存がない遠いところにあることがわかります。

SOLID Go Design | Dave Cheney というブログには大事なことが書かれていますので読みましょう。

All things being equal the import graph of a well designed Go program should be a wide, and relatively flat, rather than tall and narrow.

この言葉はとても共感できます。

端末インターフェース

今回、tcellというパッケージを使ってみました。 termbox-goよりも後発で、様々な改善が行われています。 SimulationScreen というスクリーンのmockがあって、描画のテストをしやすいのはよいですね。 あと、テキストのスタイルをメソッドで更新していけるのは便利です (Goに三項演算子がないからかもしれません)。

Go言語という選択

最後になってしまいましたが、実装の最初に考えることは、どの言語を使うかということです。 バイナリを不安なくきちんと扱えること、環境にできるだけ依存せず実装できること、そして開発者にインストールしてもらいやすいことあたりが必要条件でした。

Go言語のデザインや型のシステムは決して私の好みではありませんが、言語の選択を左右するのは言語デザインだけではありません。 バイナリの扱いやすさ、言語の安定性、実行速度、ポータビリティー、コードの書きやすさ、メンテナンスのしやすさ、そして言語の人気とツールのインストールされやすさ (インストール時の心理的障壁の低さ) など、総合的に考えてGo言語はとてもよい言語だと思っています。

まだ実装していませんが、今後ファイルフォーマットを解析する機能を作ろうとしています。 画像ファイルや実行ファイル (ELF・Mach-Oフォーマット) などの解析コードが標準パッケージに入っているのは、Go言語のすごいところです。 他の言語だとライブラリをがんばって探すか、自前で解析するしかないでしょう。

goroutine間でデータを共有すると、簡単にraceが起きてしまうのが悩ましいところですが、これは丁寧にロックを取ってraceが起きないようにしなくてはいけません。 go test -race で簡易なチェックをできるのはよいですね。

みんなのGo言語【現場で使える実践テクニック】

いい本です

まとめ

バイナリをエディットしたかったので、バイナリエディタを作りました。 作る過程で様々なことを学ぶことができました。

まだ実装したいことはたくさんあります。 diffモードやマーク、バイナリ列での検索などは実装する予定です。 実行ファイルのフォーマットを勉強して、ファイル構造を表示できるようにしたいと思っていますが、これは少し先の話になりそうです。 画像ファイルくらいから始めるかもしれません。

バイナリエディタ作りの旅は始まったばかりです。 各種ファイルフォーマットを調べながら、エディタ作りを楽しもうと思います。

宣伝

はてなでバイナリをエディットする仕事はあまりありませんが、プログラミングが好きで自分が使うものは一から作ってしまう、そんな情熱あふれるエンジニアを募集しています。

*1:ファイルの最後に飛び、ファイルサイズを取得するのに用いられています。

*2:壁をグラフの辺とみなして頂点の次数に着目します。どんな分割や分割解除を行なっても、縦方向と横方向に見て、次数が3なら1、4なら2を足したもの (すなわち分割線の端を1と数える) の中に、必ず1つは偶数があることを示せば証明できます。四畳半は3と1しかなく、偶数がないため作ることはできません。四畳半レイアウトでなくても、適当に分割を解除して全て奇数になれば作れないレイアウトです。

*3:まだ複数のインターフェースがあるわけではないので、どれだけ簡単かはやってみないとわかりませんが…

*4:Goは構造的部分型なので、抽象に依存させるために、抽象の置き場所に悩むことがないのがよいですね。

*5:汎用的なコードの依存関係の抽出ツール rexdep を作りました！ ― 正規表現で依存関係を大雑把に抽出しよう！ - プログラムモグモグ

2017年を振り返って

今年は仕事で関わっているプロダクトが大きな転換期を迎えて、様々な経験ができました。 ミドルウェアを自ら作り上げ、データをオンラインで移行し、運用を始めるというのはなかなか経験できないことだと思います。 サービスは以前より安定し、穏やかな年末を過ごしています。

今年は初めてカンファレンスで登壇しました。 慣れないことばかりで色々と戸惑いましたが、沢山の方に発表を聞きに来ていただいて嬉しかったです。 マネージドサービスを組み合わせて1つのソフトウェアを作り、それをサーバーレスミドルウェアとして抽象度を上げて捉えることができるようになったもの、このカンファレンスに参加してよかったことでした。

今年は19記事書きました。 特に、以下の記事は多くの方に読んでいただきました。

一年の後半にアウトプットが減速しているのは、カンファレンスの登壇に体力を使ってしまったこと、Prime VideoやAbemaTVを見ながらぼーっとする時間が増えたこと、プロダクトコードのリファクタリングに随分と入れ込んでしまったことなどが原因だと思います。

年始はコンパイラーやインタープリターに興味があり、インタープリターを書いてみたりLLVMを試したりしていたのですが、3月ぐらいには興味も薄れていきました。8月くらいまでは仕事が忙しく余裕がありませんでしたね。その後Rustを真面目に書き始め、システムコールに興味を持ち、そしてMackerelのシステムメトリックに興味が移り、go-osstatを作り始めました。最近はエディターの実装に興味を持ち、色々と調べています。ことごとくトレンドを外した感じに共感を持てますね、まぁ自分のことですが。

Vim周辺の変化で言うと、vimshellを辞めてterminalを使いだしたことくらいですが、他はほとんど変化はありませんでした。lightlineのスター数は順調に伸び、2500を突破しました。ユーザー数は増えてもissue報告はそんなに増えていないし、ほとんどが設定の仕方に関する質問なので楽なものです。

今年は投資を始めた年でした。これまで一切経済のニュースとか興味がなかったのですが、今のペースで経済が成長していくと現金で持っているのがアホらしく思えてくるので、少しずつ時間を取って勉強し始めています。まだド素人なので特に語れることはありません。

生活面、仕事面共に大きな変化はありませんでしたが、緩やかに成長できた一年だったと思います。来年は少しずつアクセルを踏んで頑張っていきましょう。

山村美和「なんでも本気でやるから楽しいんじゃん。」

ばらかもん

Go言語のsyscall.Sysctlは最後のNULを落とす

カーネルのパラメータを引いたり設定したりする時に便利なのが sysctl コマンドです。

 $ sysctl kern.ostype
kern.ostype: Darwin

このコマンドのシステムコールをGo言語から叩いて、OSの種類を引いてみましょう。

func main() {
    ret, _ := syscall.Sysctl("kern.ostype")
    fmt.Printf("%s\n", ret)
}

Darwin

問題ないですね。 数字を返すものを叩いてみましょう。

 $ sysctl machdep.cpu.feature_bits
machdep.cpu.feature_bits: 9221959987971750911

func main() {
    ret, _ := syscall.Sysctl("machdep.cpu.feature_bits")
    val := *(*uint64)(unsafe.Pointer(&[]byte(ret)[0]))
    fmt.Printf("%d\n", val)
}

出力結果

9221959987971750911

unsafeパッケージは使いたくないだって？ アーキテクチャのエンディアン固定になっちゃうけどなぁ。

   val := binary.LittleEndian.Uint64([]byte(ret))

9221959987971750911

次は extfeature_bits を見たい？

 $ sysctl machdep.cpu.extfeature_bits
machdep.cpu.extfeature_bits: 1241984796928

func main() {
    ret, _ := syscall.Sysctl("machdep.cpu.extfeature_bits")
    val := binary.LittleEndian.Uint64([]byte(ret))
    fmt.Printf("%d\n", val)
}

実行してみます

panic: runtime error: index out of range

goroutine 1 [running]:
encoding/binary.binary.littleEndian.Uint64(...)
    /usr/local/Cellar/go/1.9.2/libexec/src/encoding/binary/binary.go:76
main.main()
    /private/tmp/main.go:16 +0x1d7
exit status 2

！！！＞ index out of range ＜！！！

なにが起きたのか。 syscall.Sysctl の返り値 (string) の長さを見てみると、すぐにわかります。

ret, _ := syscall.Sysctl("machdep.cpu.feature_bits")
fmt.Printf("%d\n", len(ret))
ret, _ = syscall.Sysctl("machdep.cpu.extfeature_bits")
fmt.Printf("%d\n", len(ret))

8
7

え、つまりこれは… https://github.com/golang/go/blob/8776be153540cf450eafd847cf8efde0a01774dc/src/syscall/syscall_bsd.go#L474

   // Throw away terminating NUL.
    if n > 0 && buf[n-1] == '\x00' {
        n--
    }
    return string(buf[0:n]), nil

な、なんということを…

つまりstructでも…？

ret, _ := syscall.Sysctl("kern.boottime")
fmt.Printf("%d\n", len(ret))

15

お、おう… わかった… わかったよ…

• sysctl.Sysctl は最後のNULを落とす。
• 文字列を返すような場合はよい挙動だが、数字や構造体の場合は注意が必要。64bit整数を返す場合、その値に依存して8byteだったり7byteだったりする。
• unsafe.Pointer で数字や構造体にキャストする分には問題ないように思われる (ほんまやろか？)。 + "\x00" してから処理したほうがいいかもしれない。

困っている人もいる (例) が、指摘されているように sysctl パッケージは変更を受けつけていないので、この挙動が変わることや別の関数が追加されることはなさそう。 そもそも string で返すのなんかおかしくない？ []byte で欲しいよね…

それあります！ golang.org/x/sys パッケージの unix.SysctlRaw を使いましょう。 https://github.com/golang/sys/blob/53aa286056ef226755cd898109dbcdaba8ac0b81/unix/syscall_bsd.go#L524

func main() {
    ret, _ := unix.SysctlRaw("vm.loadavg")
    fmt.Printf("%d\n", len(ret))
    ret, _ = unix.SysctlRaw("kern.boottime")
    fmt.Printf("%d\n", len(ret))
    ret, _ = unix.SysctlRaw("machdep.cpu.extfeature_bits")
    fmt.Printf("%d\n", len(ret))
}

24
16
8

これで安心して眠れそうですね。

sysctl.Sysctl は最後のNULを落とします。文字列として欲しい時はこれで良いが、バイト列として欲しい時は unix.SysctlRaw を使いましょう。

Go言語のHTTPリクエストのレスポンスボディーとEOF

Reader interface の Read 関数は、どのタイミングで io.EOF を返すのでしょうか。 まずは strings.Reader で見てみましょう。

package main

import (
    "fmt"
    "strings"
)

func main() {
    r := strings.NewReader("example\n")
    for {
        var b [1]byte
        n, err := r.Read(b[:])
        fmt.Printf("%d %q %v\n", n, b, err)
        if err != nil {
            break
        }
    }
}

結果

1 "e" <nil>
1 "x" <nil>
1 "a" <nil>
1 "m" <nil>
1 "p" <nil>
1 "l" <nil>
1 "e" <nil>
1 "\n" <nil>
0 "\x00" EOF

Readの結果は、読み込んだbyte数です。なにもなくなってから io.EOF を返していることがわかります。

ファイルだとどうでしょうか。

package main

import (
    "fmt"
    "os"
)

func main() {
    f, err := os.Open("main.go")
    if err != nil {
        fmt.Fprintf(os.Stderr, "%v\n", err)
        os.Exit(1)
    }
    defer f.Close()
    for {
        var b [1]byte
        n, err := f.Read(b[:])
        fmt.Printf("%d %q %v\n", n, b, err)
        if err != nil {
            break
        }
    }
}

1 "b" <nil>
1 "r" <nil>
1 "e" <nil>
1 "a" <nil>
1 "k" <nil>
1 "\n" <nil>
1 "\t" <nil>
1 "\t" <nil>
1 "}" <nil>
1 "\n" <nil>
1 "\t" <nil>
1 "}" <nil>
1 "\n" <nil>
1 "}" <nil>
1 "\n" <nil>
0 "\x00" EOF

同じですね。

ではHTTPリクエストだとどうでしょうか。

package main

import (
    "fmt"
    "net/http"
    "os"
)

func main() {
    resp, err := http.Get("http://example.com")
    if err != nil {
        fmt.Fprintf(os.Stderr, "%v\n", err)
        os.Exit(1)
    }
    defer resp.Body.Close()
    for {
        var b [1]byte
        n, err := resp.Body.Read(b[:])
        fmt.Printf("%d %q %v\n", n, b, err)
        if err != nil {
            break
        }
    }
}

1 "<" <nil>
1 "/" <nil>
1 "h" <nil>
1 "t" <nil>
1 "m" <nil>
1 "l" <nil>
1 ">" <nil>
1 "\n" EOF

なぜなのか… なぜなのか！！！

検索するとruiさんのエントリーが出てきました。 qiita.com (三年前の記事だった… もしかして… これは常識なのか！？) そして、mattnさんがgolang-nutsでスレッドを立てられていたのでざっと見ました。 Issue 49570044: code review 49570044 も勉強になります。 これはContent-Lengthがセットされたレスポンスボディーを最後まで読んだ後に、すぐにコネクションを使いまわせるようにするための意図した挙動であるということがわかりました。

Readerはわりと使い慣れたinterfaceなのにハマってしまいました。 Go言語を書いていると手癖ですぐにerrを返してしまいがちですが、Readは読み込んだバイトがありながら io.EOF になることがあることに気をつけなくてはいけません。 いや、これはruiさんの記事を同じことを言ってますね… ほんとは常識なのかもしれない…

ライブラリーが Reader 使ったインターフェースを公開しておきながら、io.EOF の扱いが適切でないと簡単にバグを踏んでしまいます。 strings.Reader でテストして満足していると、resp.Body に繋いだ瞬間なぜか挙動が変わるということがあるかもしれません。

Read の返り値のバイト数を捨ててませんか？ err != nil でもデータを読み込んでいるかもしれませんよ？

みなさん、気をつけましょう。おわり。

zshの標準エラー出力の色を赤くする

最近stderrを赤くするように設定したら、コマンドの出力がかなり見やすくなりました。

設定はこんな感じに書いてます。

zmodload zsh/terminfo zsh/system
color_stderr() {
  while sysread std_err_color; do
    syswrite -o 2 "${fg_bold[red]}${std_err_color}${terminfo[sgr0]}"
  done
}
exec 2> >(color_stderr)

fg_bold[red] のところを fg[red] とかbg_bold[red] とかするとスタイルを変更できます。 古いzshでは動かないらしいので、古い環境も気にしたい場合は is-at-least 4.3.4 でチェックするとよさそうです。

この設定の元ネタはcoloring stderr - was Re: piping stderrです。 大体はうまくいくし、普段使う分には大きな問題は起きていないのですが、わりと乱暴なことをやっているという自覚はあります。 元ネタのスレッドでも触れられていますが、 echo L1; echo L2 >&2; echo L3; echo L4 >&2 とやると L2 と L3 が逆に出力されたりします。 あと bash -i したあとに top を起動できないといったりします。

いくつか問題が起きるケースはありそうだけど、二週間ほど試してみて普段端末を触る範囲では困っていないのと、stderrに色が付くのがありがたいので使っています。もっといい方法があれば教えてください。

ついでに使っているPROMPTの設定はこんな感じです。終了コードを元に色を変更しています。

PROMPT="%(?.%{$fg[green]%}.%{$fg[blue]%})%B%~%b%{${reset_color}%} "
PROMPT2="%{$bg[blue]%}%_>%{$reset_color%}%b "
SPROMPT="%{$bg[red]%}%B%r is correct? [n,y,a,e]:%{${reset_color}%}%b "