にゃははー

はへらー

msgpackのデバッグをするための何か

msgpackのデータはあるんだけどなんかズレてたりしてデシリアライズ出来なくて困った困ったみたいなとき、目デシリアライズするのも(でかいと)ツライし、そうでなくてもデバッグしてる間に中身を見ようとしてもVSのデフォルトのビジュアライザだと中途半端でつらいものがあった

一応ブラウザで動くビジュアライザもあるらしいがbase64にしないといけないっぽいし、でかいデータでも大丈夫なのかな、、とか、(多分)オフラインだけどちょっと機密データのデバッグには抵抗感がある http://sugendran.github.io/msgpack-visualizer/

Visual Studioのデバッガは優秀(真顔)だけどvisualizerもmsgpack的にはちょっと足りない

つくったもの

msgviwer

https://github.com/Flast/msgviewer

とりあえずバイナリデータをツリー状にして可視化する

単にツリーで見えても修正とかだるかったからオフセットも見えるようにしてる

Qtで作ってるから大体の環境で動くはず

ビルド方法とかドキュメントとか無いのはなんとかしないといけない(使命感)

msgpack-vs-visualizer

https://github.com/Flast/msgpack-vs-visualizer

Visual Studioのデバッガで配列とか中身全部みれるようにするやつ

こっちもドキュメントとか全然ないけど雰囲気でがんばって(適当)

とりあえず配列のようなやつらは全部ちゃんと見えるようになった

余計な via とか見えてるのは気が向いたらそのうちなんとかしたい

allocaをinline関数で使うと危険である?

“allocaをinline関数で使うと危険である"という要旨のメールがoss-securityに流れてて、これは一体どういうことだ…と思った。

長い文章でも無いしそんなに難しくもないが、どうやらGCCオプティマイザの展開順に問題があるようだ。

http://www.openwall.com/lists/oss-security/2017/04/10/18

曰く、alloca(本文ではC(99)のVLAを指していた)を見つけるとGCCはそれを__builtin_allocaに展開した後、そのinline関数をインライン展開するので、ループ中で使うとスタックをガンガン持ってかれるということだった。 allocaは任意のスコープではなく、関数スコープからの離脱でのみスタックの巻き戻しを行うので、ループ本体を一巡したあとに本来巻き戻って欲しいスタックが巻き戻らず、次のallocaが行われてスタックが枯渇する脆弱性になると指摘している。

試しにMLに張られたコードに足りない部分を補完してバイナリを見てみたが、どうにも普通に巻き戻しはしているように見える。 -Oから既にインライン展開は行われるが、いくつかの最適化レベルを眺めてもやはり巻き戻しているように見える。

https://godbolt.org/g/fiofnf

なにか別の要因があるのだろうか…

スレッドアンセーフなshared_ptr

多分みなさんはstd::shared_ptrを使ってるとシングルスレッドで使うんだからスレッドアンセーフでいいのにとか思うことが良くありすぎて再実装したくなると思います。ならない方はなって下さい。設計が悪いと言う人はrecursive mutexを今後使わないで下さい。

はい。

で、libstdc++にはそういう拡張があるらしいです。 ドキュメントにはないけど。

基本的に使い方はstd::shared_ptr(と関連するもの)と同じだけど、第二テンプレート引数を受け取る点が違ってて、このテンプレート引数でMT-safe-nessを指定する感じになっている。

bits/shared_ptr_base.h melpon.org

執筆時点で定義されているのは3通り

  • 完全にunsafe
  • ミューテックスを使ってアトミックにカウント
  • アトミックカウンタを使ってアトミックにカウント

ext/concurrence.h

デフォルトのポリシーはスレッドサポートがあるかどうかとCPUのアトミック命令のサポートがあるかどうかで変わるぽいです。

なので、明示的にstd::_S_singleを渡せばMT-unsafeなshared_ptrが手に入ります。 ヤッター!

演算子における引数の評価順と副作用

年も瀬だというのにTwitterで規格書たちが騒いでいたのは記憶に新しい(?)と思うけど、自分もC++11(とちょっとあと)までしか読んでなかったせいで、いろいろ時代の潮流に取り残されている感じがあったのでちゃんと自分で調べましたっていう話。

事の発端と反応はおおよそこちらにまとまっているので参照されたい。

paiza.hatenablog.com

現時点でC++17として正式に規格が発行されたわけじゃないので本文中ではC++1zとし、最終的にISとなった場合にさらに追加で変更されている可能性もありますので、注意してください。

続きを読む

Boost.Fusion, Boost.Phoenixのメンテナになりました

今朝見慣れないメールがいくつか飛んできていて、その中でJoel de Guzman(FusionとかPhoenixとかSpiritとかのAuthor)が、「君をメインメンテナとしてコミット権追加しといたから、ヨロシク」ってなてました。

Boostの開発はgithubに移行してからpull-requestすれば誰でも参加できるものだったので、特にコミット権は不要で(ただしコミット権持った人が反応しないとめっちゃ滞る)、まぁいいかなってFusionとか100個ぐらいpull-requestガシガシ投げてたんですが、最近Phoenixもいじるようになって流石に面倒になってきたんでしょうか... 当のJoelはSpirit.X3の開発に専念したいみたいですし。

コミット権あっても何でもやっていいわけではないので、明らかなtypoとかテスト追加とかは直接やるとして、結局はpull-request出してセルフマージしていく感じになると思います。明らかな破壊的変更は他の人のレビューも待って誰かにマージしてもらう感じで。

インクルードガードとpragma once

C++ Advent Calendar 2015の5日目です。

C++時代から近代C++に至るまで、ヘッダファイルの重複インクルード排除のために通称インクルードガードというものが使われてきました。

#ifndef YOUR_VERY_VERY_AWESOME_LIBRARY_HEADER_H
#define YOUR_VERY_VERY_AWESOME_LlBRARY_HEADER_H

#endif // YOUR_VERY_VERY_AWESOME_LIBRARY_HEADER_H

しかしこれはファイルの前後に書かないといけないという制約や、他のヘッダとトークン列が一致してしまうと意図せずヘッダがインクルードされないという問題がありました。

これに対してたった1行で書いて終わりの#pragma onceは、標準化を求める声も多く、目的が明確で、実装もあるにも関わらず、標準に入る気配すらありません。 twitterとかでもそういう声をたまに見るのですが、ちょっと考えれば難しそうだというのがわかってもらえるかと思うので、ここでまとめておこうと思います。

続きを読む

Boost.勉強会 #18 大阪

今日Boost.勉強会が開催されていたらしいので、そういう感じのタイトルにしておけばタイムリーかなって思いました。(小並感

さて、思い立ったがなんとやらという言葉がありますが、思い立ったので秩父神社まで日帰りで行ってきました。 予てより八意思兼命を祀っている秩父神社には参拝したいと思っていたところ、友人が(秩父神社ではないが)御朱印帳を取り出して見せてくれたりしたので参拝意欲が俄然高まってしまった。

ということで池袋から西武で一路秩父へ。

飯能から先、横瀬までの間の峡谷風景がとても良かった。

まだ横瀬だというのに、やたらテンションが高くなってしまったのがTLにいたようだ(なお一人旅)。

西武秩父から秩父神社は十分歩ける距離らしかったので、歩いて街の景観を楽しんでいたのだが、やはり

ということで歩くこと7分程度、ようやくたどり着いた。

あまり神社仏閣を写真でぱしゃぱしゃするのは好きではないので、一通り見て回って最後に御朱印を頂いてきた。

知恵の神だからだろうか、帰りの電車内でコードを書いたがそれなりのシンチョクは得られたように思う。

帰りがけには地酒を数本買い、またいつか来ようと思った。 次はもっと時間に余裕を持って(泊まるぐらいの勢いで)横瀬の手前でも途中下車したいと思った。

池袋に降りた時、俗世へと戻ってきてしまった後悔が若干あった。。。