読者です 読者をやめる 読者になる 読者になる

yamaguchi.txt

開発日記。備忘録代わりだよ。

QTcpsocketがwriteされない時

全くwriteされない、もしくは意図していたのと違うパケットがtcpでwriteされてしまった場合、デフォルトで有効になっているNagleのアルゴリズムが原因かもしれません。

できるだけまとめて送られてしまうので、逐次的にwriteしたい場合などはsocket->waitForBytesWritten();をwriteの後に書くと正しい挙動になってくれます。

socket->write("hoge");
socket->waitForBytesWritten();

QAbstractSocket::LowDelayOptionでNagleを無効にできると公式ページでは書いてありますが、少なくとも私の環境では無理でした。

留年の、その後

前書き

三月の中旬にfacebookツイッターで留年した旨を報告しました。
新学期が始まってから、いろんな人に"今どうなってるの?"と聞かれることが多いので、現状を綴ろうと思います。心配や気にしていただいた方、本当にありがとうございます。

結論から言うと:
理情の授業にもフルに出れていて、他の活動も色々としていて、人生が超充実しています。
本当に背水の陣であることには変わりがないのですが、私は追い詰められたほうがハイになってパフォーマンスが上がるタイプみたいです。

以下、経緯を詳しく説明します。

留年した経緯

前期教養の総合科目のE系列を勘違いしていました!

総合科目を"E,F系列に渡って"取らないといけなかったのをF系列しか取っていませんでした。
私の他に3人、全く同じ原因で留年した同級生がいます。
新入生はほんと気を付けましょうね、教務課は何の連絡もしてくれませんから。

理情の授業に出れることになった経緯

制度についてご説明

東大の一二年生は入学したら全員教養学部という所に入れられます。教養学部と三四年生の工学部、理学部などは事務の方が"教養学部は別の大学って感じだから…"と言うくらい離れた組織です。

私は理学部に内定していたのですが教養学部を卒業できなかったため、理学部に進学できないという状態です。

教養学部と理学部は別の組織なので理学部の方からどんなに言っても教養学部で出た留年という判定を覆すことはできません。

今回の措置

今回私が特例で認めてもらった措置は(大部分の科目について)今年度普通に実験、テストなどを受けたら、来年の進学後に単位が降ってくるというものです。前例はないらしいです。
(大部分の科目について)というのは、4つの講義でまだこの件に関して教授に相談ができていないが、それ以外の科目については認められそうである、ということです。この4つの講義というのは全部座学でテスト科目なので、最悪の場合でも来年テストだけ受ければ良いので負担は全然重くないです。

ロッカー、パソコン、wifi…なども支給していただき、毎日本郷に通い、三年生と全く変わらない待遇を受けさせてもらっています。
唯一違うことは、私の学生証が教養学部のもので理学部のものではないので、深夜や土日など七号館の鍵が閉まっている時に私の学生証じゃカードリーダーが通してくれないということくらいです。しかし、他の人と一緒に入ればいいだけなので全然大した問題じゃありません。

特例を認めてもらえた経緯

三月末にいきなり学科長からお呼び出しがあり、今回のような人権が認められる措置になったことを告げられました。
留年してから事務の方とも密に連絡を取っていたし、理情の仲の良い先生が学科長に怒りのメールを送ってくれていたらしく、(それでなのかは知りませんが)教授会議が開かれ決定したみたいです。

留年した当日から直ぐに本当に色々な人 (理学部や理情や仲の良い先生や、受かっていたSVAPプログラムの事務局や(SVAPに関しては理学部のプログラムなので行けなくなりました)、先輩方、facebookツイッターなど) に報告や相談をして連絡を取っていたおかげだと思います。相談やアドバイスをくれた方、本当に本当にありがとうございます。

教養学部の授業

理情の授業に出つつも、不足しているE系列などを取るために駒場に通わないといけません。
S1の一単位だけで終わるE系列と、文系総合科目を取ることにしました。
時間割はこんな感じになります。

今学期はどうするのか

ここまで色々やってもらったのに中途半端な成績を取るわけにはいかないし、駒場の点数も下げるわけにはいかないので、授業を優先して色々活動をします。
普通に留年して暇になるものだと思って応募してしまった時間が取られるプログラムもあり、もし仮にそれに受かったりしたら本当にヤバいです。これに関しては結果が出ていないので未定ですが。
他にも、バイトは楽しいし、最近clangにパッチを投げたりなどしてOSS活動ももっとできたらいいな、と思っているのでやることはたくさんあります。大学入ってから一番忙しいかもしれません。

過労死することはあるかもしれませんが、鬱病で死ぬことは絶対にないのでその点に関しては安心していただければなと思います

今後ともよろしくお願いいたします。

techgirlでLTしたよ

昨夜は@kamapuさんにお誘いいただき、techgirlというイベントに参加してきました。


techgirl.doorkeeper.jp

みなさん普通にIT企業にバリバリ勤めていらっしゃる方が多く、普段あまり外の世界と関わらない私にとっては"世の中にはこんなに女性エンジニアがいるんだなぁ"という感動がありました。
LTでは仕事の話が多く私が発表した"/etcを歩く"は完全に浮いてしまっていたのですが、会社の人ってこんなこと考えてるんだーと勉強になりました。
今度からはもっとウケのよさそうな話題を提供するぞ…。

/etcを歩く

/etcのファイル・ディレクトリの小ネタです。
会場がハートビーツさんというサーバー管理の会社で、完全に釈迦に説法状態になっていて怖かったです。

一応スライドはあるのですが、口頭で話すつもりだったので情報量が0なので是非画像の方を見てください。

www.slideshare.net


f:id:yamaguchi_1024:20170409012915p:plain
話そうと思っていた内容は
・thermaldとかいうの、CPUの周波数を監視して冷却するデーモン
・brlapi.key brltty 盲目な人用の点字ディスプレイデーモン 
・magic スペシャルファイル。Fileコマンドが使用するmagicファイル。例えばelfなら7f45からはじまるマジックナンバーを見て、どのファイルか決める
・security ユーザーごとのリソース制御 cpu何コアとか、メモリ何ギガとか
・securetty rootがログイン可能なターミナル tty0,1…
・init系 init と init.dの違い。Linuxで初めに立ち上がるinitデーモンで、古いSysV init の定義ファイルがあるのがinit.dで、新しいUpstartの定義ファイルがあるのがinit. Initのほうが新しいんですね。
・network 基本的な設定。よく使うやつ。
・networks デフォルトは空。ネットワーク名とネットワークアドレスの対応を書く
・subgit gitをsubversionに移行
・passwd ユーザー名、ホームディレクトリ ここにはパスワードは書かれていない,shadow パスワードの実態
debian_version,os-release,lsb_release,issue ディストリやバージョンを取得



半分も話さないうちに時間切れになってしまいました…。
タイムマネジメントしような。

サイバーコロッセオに参加したよ

3/5に秋葉原で行われたサイバーコロッセオ×SECCONというCTFの大会にチーム_hodge+mamaとして参加しました。結果は10位。まぁまぁです。
東京2020公認プログラムらしいです。あまり意味は無さそうですが承認欲求が満たされますね。

今回はオンサイトなのでking of the hill方式ということで、jeopadyとはちょっと変わった感じでした。
可視化エンジンはNIRVANA改で、攻殻CTFの時に見たAMATERASとはちょっと違う気もしました。NIRVANAのほうが若干オシャレな気がします。

今回の教訓は、絶対に性能の良いノートPCを買おうな!!!!!ということです。
素因数分解、scapy等ちょっと重い処理をさせたらフリーズし、競技中10回は電源をブチ切ったので頭の血管が破裂しそうでした。

個別の問題の感想はディスりになってしまうので省略しますが、SECCONだなぁ…という感じでした。
第六問の謎プロトコルモールス信号を二時間くらい考えて思いつかなかったのは本当に世界一頭が悪かったと思います。深く反省しています。
競技時間が短いからか、時間がかかるrevとかpwn系よりも思いつくか思いつかないか、知ってるか知ってないか系の問題が多かったと思いました。


f:id:yamaguchi_1024:20170306213756j:plain
f:id:yamaguchi_1024:20170306213807j:plain
NIRVANA改。おしゃれですね?

f:id:yamaguchi_1024:20170306213814j:plain
f:id:yamaguchi_1024:20170306213837j:plain
SAO好きにならねば…。と思って見たのですが安直なハーレム的な感じが好きになれませんでした。攻殻機動隊でいいよ。

f:id:yamaguchi_1024:20170306213844j:plain
証明がめちゃくちゃ青かったので自殺防止か?と思いました。

鬼畜眼鏡布教ブログ

高校生の時からやってみたいなと思っていた、鬼畜眼鏡という18禁BLゲームをプレイしました。
ありえないくらい良かったので布教するために記事を書きます。

まぁとりあえずOPを見てみてください。いいですよね。
www.youtube.com


今までやった18禁ゲーム(とは言っても恋姫無双と沙耶の歌しかないが)の中でシナリオがダントツに良く、今までの人生の中で初めて主人公が一番好きになりました。
BL好きな人でも好きじゃない人でも、誰にでもおすすめできるゲームです。鬼畜とは言ってもそこまでハードな凌辱はないし、何といってもシナリオが神なので是非プレイしてほしいです。

あらすじ

(公式HPより)
何をやっても裏目に出てしまい、失敗ばかりの営業マン、佐伯克哉。
リストラを目前にして、半ばあきらめていた彼の前に現れたとある人物。

  「これを身につけた瞬間から、あなたの人生は大きく変わります」

そういって手渡された、なんの変哲もない眼鏡。
それをかけた瞬間から、彼の人生は180°変わり始めた――。

その眼鏡をかけている間は、人が変わったように有能に仕事がこなせるようになったのだ。これで俺は今までの駄目な自分を捨て、変わることができる。

しかし、断片的によみがえる眼鏡をかけているときの自分の行動。 
これは本当に俺なのか? 一体俺は何をしているんだ?
そう、その眼鏡は、なんとかけた者を鬼畜に変える禁断のアイテムだったのだ…。

眼鏡の着脱によって、弱気な主人公(受)から鬼畜な主人公(攻)へと変身できる、アダルトリーマンラブストーリー。


感想

太一ルート→本多(ノーマル)→片桐→御堂(ノーマル)→本多(眼鏡)→アキ→御堂(眼鏡)
の順で攻略した。

太一ルートはシナリオが厚く説得力があり本当に良かった。太一の言動は納得できる人が多いのではないだろうか。
太一は克哉の家の近くにある喫茶店の店員。ちゃらんぽらんな感じがする一見普通の大学生だが、ストーリーを進めると太一の育った環境やその倫理観に驚くことになる。
歪んだ愛情ルートは最高だった。太一は克哉のことを「ここにいるのに、いない」と形容していたが、歪んだ関係になってしまうルートでは、克哉のことをどれだけ凌辱して侍らせても自分のものになったという満たされない気持ちだったんじゃなかろうか。救われなくて最高。
太一ルートと本多ルートは受け克哉が一番幸せになるルートなんじゃないだろうか。


片桐はあまり期待していなかったが、結果的には激シコだった。バツイチの課長がメンヘラ乙女だって誰が想像する?
仕事の能力も低く誰にも必要とされていないと感じ続けた片桐にとって、凌辱という行為であっても眼鏡克哉が自分を必要としてくれるのが嬉しかった。バッドエンドの刺殺ルートも他のキャラの刺殺よりCGがあるなど気合が入っており、メンヘラ感が出ていて非常に良かった。
「それは、僕が気が利かないおじさんだからかい?」
眼鏡克哉に凌辱され依存させられて捨てられた時に縋りついていったセリフがこれって、どんだけいじらしんだよという感じだった。
バッドエンド快楽落ちの時の「次は、僕も…」というセリフも可愛くて最高だった。


本多ルートは、王道というか克哉の心の闇を一番理解して慰めてくれるルートだった。
本多は克哉の同期で同僚で、ウザいくらい熱血な男なのだが、克哉との心の摩擦というかすれ違いがアツくて最高だった。
単細胞脳筋な所は攻めでしかなく、ノーマル克哉に対する優しい攻めはもちろん、眼鏡克哉に対しても対等?に攻めようと努力し(受けだが)ちゃんと自我を保っているところがすごい。
約束された攻めという感じ。


御堂攻めルートは王道凌辱という感じ。まあ普通?個人的には電話口であえぐ克哉の声を聴いて好きになっちゃう本多が救われなさ過ぎて好きだった。
御堂受け、あまり期待してなかった分刺激が強かった…。御堂ただでさえ美しいのに一年後に告白した時のCGが絵になりすぎて泣いた。
君は、強姦されると好きになっちゃうタイプのフレンドなんだね!って思っていた。
どれだけ凌辱されても絶対に屈しない芯の強さはもちろん、あんなことされても好きと言われただけで憎しみから愛情に変わってしまう繊細なところも最高。


アキは、ビジュアル的には好みなのだがシナリオが薄い感じがした…。残念…。
受けはアキみたいな淫乱猫みたいな感じより、堅物で真面目だけど弱気…みたいなのが好きなので微妙だった。
もうちょっと一ひねりあっても良かったんじゃないかな?


個人的には、学園ものなんかよりも舞台が会社でビジネスビジネスしているところがツボだった。世の中のリーマンすべてに優しい気持ちを持てるようになった。
エロシーンも良いのだが、それよりもホモが哲学しているシーンが好きということに気が付いたので、そういうゲームがあればぜひ教えてほしい。


ノーマル克哉は本当に最高で、こんなにMで可愛くて幸せにしたくなってシコい主人公はいないと思う。太一は「克哉さんって幸薄そうな感じ・・・。幸せにしたくなる感じ!」と言っていたが、本当にそうだし太一とはつくづく気が合うなぁと思う。
BLの主人公は幸薄そうであればあるほど、そこから救い出してくれる攻めが愛おしくなるから良い。
片桐とノマ克はまさに優しい弱気リーマンで、この二人に幸せになってほしいと心から思うのに、二人のルートがないことがさみしい…。
どちらが攻めでもなく、ゆるゆるとお互いに支えあう生活ができると思うんだけど…。

FPGAで自作CPUを動かしてみよう (1)

この記事はIS17er advent calendarTSG advent calendar の15日目の記事として書かれました。cookies146、お誕生日おめでとうございます。これは、お誕生日プレゼントを作ろうとする試みです。

FPGAでCPUを動かすことについて、ISの先輩の記事などから断片的な知識は得られるのですが設計など全く分からない初心者が全体像を把握したいような時に読める記事が無かったので書きました。間違いがあったら指摘してください。
いつになるか分かりませんが一応続くつもりです。

今日の話は、物理的に必要なもの(購入が必要なもの)と漠然とした設計の話です。

とりあえず、必要なもの

FPGAスーパーキット(これがないと始まらない)

・ MAX10-FB基板用の追加部品
   ・発振器
   ・ピンヘッダ2*40
   ・ピンヘッダ1*40
   ・ピンソケット1*40
   ・ピンソケット2*20
   ・ジャンパピン
   ・SDRAM(オプション)
・MAX10-JB基板用の追加部品
   ・PICマイコン
   ・レギュレータ
   ・LED緑
   ・LED黄
   ・ポリスイッチ
   ・水晶発振子
   ・抵抗の中から120,130,10k,10k,2,2kΩ
   ・電解コンデンサ*2
   ・積層コンデンサ0.1μF
   ・積層コンデンサ22pF
   ・USBコネクタ

環境構築

スーパーキットの本に従って、基盤の組み立てとQuartusの導入、FPGAでLチカくらいまでしましょう。(所要時間10時間)
良ければこの記事を参考にして下さい。

設計の雰囲気

お手本にするアーキテクチャMC6800で、一応先行研究としてこんなブログを発見したが、途中で途切れているのでネタの被りはなかったことにします。この記事だって途中で途切れるかもしれないし。MC6800にしたのは8bitCPUが作りたいとハードウェアの先生に相談したところ、おすすめされたため。

具体的な話は今度にして、とりあえず何を作って何を作らないかを明確にする。

イメージ的にはこんな感じ。RAMとROMはQuartusのwizardという機能でサクッと作れるので、実際にHDLを書くのはcontrolerとALUになる。
f:id:yamaguchi_1024:20161215054318p:plain

現在CPUのモードを3つ考えている。
1.ラズパイのGPIOから信号を受け取りRAMの開始番地から書き込む
2.RAMから命令をfetchし、実行する
3.実行結果をラズパイに送る
1,3は外部と通信するとそれっぽいかなというだけで、本質的には2が重要である。

1のイメージ図
ラズパイのGPIOからの通信をFPGAの外部ピンで受信し、I/O controlerを介して命令がRAMに書き込まれる。
f:id:yamaguchi_1024:20161215222101p:plain


2のイメージ図
RAMから命令がfetchされ、Decodeされてexecuteされるよ、という図。
f:id:yamaguchi_1024:20161215221706p:plain


今回はここまで。
次回はタイムチャートとブロック構成と入出力を決めたい。

32bitCPUでpkcrackを動かす話

この記事は、TSG Advent Calendar 2016 - AdventarIS17er Advent Calendar 2016 - Adventarの7日目の記事として書かれました。

駒場祭でpkcrack問を出すために、ARMでpkcrackを動かさねばならず、そのままではセグフォしたので知見を共有します。
ラズパイ2までなど、32bitのアーキテクチャで動かす必要があるときに読んで下さい。

結論から言うと

pkcrack-1.2.2/src/exfunc.cの150行目を、以下のように書き換えてからmake -Bして下さい。

`--> diff before_exfunc.c after_exfunc.c -u
--- before_exfunc.c	2016-12-07 16:06:08.297691503 +0900
+++ after_exfunc.c	2016-12-07 16:05:59.269691329 +0900
@@ -147,7 +147,8 @@
   }
   else;
 
-  data = malloc( lh.csize );
+  data = malloc( lh.csize + 100);
+  data += 100;
 
   if(!data)
   {

美しくない解決法であることは事実です・・・。が、元々のソースコードmallocのチャンクを破壊してたりfreeしてなかったりとなかなか美しくないので、許して下さい。


原因を深堀してみる

上記の書き換えを行わないと、こんなエラーが出ます。

`--> ~/tools/pkcrack-1.2.2/src/pkcrack -p buho310.pdf -P buho.zip -C easy_3.zip -c buho310.pdf -d dec.zip
Files read. Starting stage 1 on Wed Dec  7 13:42:07 2016
Generating 1st generation of possible key2_633361 values...done.
Found 4194304 possible key2-values.
Now we're trying to reduce these...
Lowest number: 974 values at offset 629645
Lowest number: 929 values at offset 629483
Lowest number: 914 values at offset 629400
Lowest number: 872 values at offset 629227
Lowest number: 845 values at offset 629213
Lowest number: 818 values at offset 629211
Lowest number: 817 values at offset 629151
Lowest number: 763 values at offset 629138
Lowest number: 699 values at offset 629111
Lowest number: 690 values at offset 629106
Lowest number: 684 values at offset 623608
Lowest number: 671 values at offset 623577
Lowest number: 640 values at offset 623571
Lowest number: 630 values at offset 623567
Lowest number: 628 values at offset 623556
Lowest number: 608 values at offset 623547
Lowest number: 549 values at offset 623529
Lowest number: 519 values at offset 623524
Lowest number: 497 values at offset 623517
Lowest number: 452 values at offset 623515
Lowest number: 447 values at offset 623514
Lowest number: 441 values at offset 623513
Lowest number: 425 values at offset 623507
Lowest number: 413 values at offset 623505
Lowest number: 401 values at offset 623481
Lowest number: 384 values at offset 623480
Lowest number: 378 values at offset 623353
Lowest number: 374 values at offset 623271
Lowest number: 371 values at offset 623258
Lowest number: 361 values at offset 623257
Lowest number: 355 values at offset 623222
Lowest number: 340 values at offset 623181
Lowest number: 325 values at offset 623173
Lowest number: 314 values at offset 623172
Lowest number: 310 values at offset 623171
Lowest number: 307 values at offset 623168
Lowest number: 285 values at offset 623167
Lowest number: 268 values at offset 600883
Lowest number: 252 values at offset 600869
Lowest number: 245 values at offset 600867
Lowest number: 222 values at offset 600866
Lowest number: 221 values at offset 600845
Lowest number: 216 values at offset 600829
Lowest number: 206 values at offset 567363
Lowest number: 199 values at offset 567362
Lowest number: 186 values at offset 567338
Lowest number: 178 values at offset 567271
Lowest number: 172 values at offset 567270
Lowest number: 171 values at offset 567269
Lowest number: 164 values at offset 567267
Lowest number: 154 values at offset 567266
Lowest number: 150 values at offset 567263
Lowest number: 149 values at offset 567259
Lowest number: 144 values at offset 567257
Lowest number: 138 values at offset 567256
Lowest number: 137 values at offset 567244
Lowest number: 133 values at offset 567243
Lowest number: 114 values at offset 567185
Lowest number: 113 values at offset 567130
Lowest number: 100 values at offset 567121
Done. Left with 100 possible Values. bestOffset is 567121.
Stage 1 completed. Starting stage 2 on Wed Dec  7 13:44:25 2016
zsh: segmentation fault (core dumped)  ~/tools/pkcrack-1.2.2/src/pkcrack -p buho310.pdf -P buho.zip -C easy_3.zip -c

gdbで実行しながらデバッグしていると、以下のことがわかります。
1.main.c(下記)の231行目でextractの戻り値をplaintextに代入して、235行目でextractの戻り値からoffsetを引いている(!)このextraxt関数の中身がexfunc.c。

231     plaintext = extract( pFromZIP, plainname, caseflg );
232     if( !plaintext )
233         exit(1);
234     plainlength = lh.csize;
235     plaintext -= offset;                                                        
236     }

2.gdbで見てみると、offsetの中身は0xc。
3.plaintext[0]~plaintext[3]にアクセスしようとするとできない。(4以降はできる!)
4.extractの返り値はmalloc( lh.csize );

32bitだとmalloc chunkがprev_sizeの4byte+sizeの4byteで8byteしかないので、12byte引くとダメなのかなと思い、上記のように修正したら治りました。
64bitだとmalloc chunkが16byteなので、12byte引いても問題なかったと考えられます。plaintext[0]~plaintext[3]にアクセスできなかったことからも、妥当かなと思います。

malloc chunkの実装を置いておきます。

1104 struct malloc_chunk {
1105 
1106   INTERNAL_SIZE_T      prev_size;  /* Size of previous chunk (if free).  */
1107   INTERNAL_SIZE_T      size;       /* Size in bytes, including overhead. */
1108 
1109   struct malloc_chunk* fd;         /* double links -- used only if free. */
1110   struct malloc_chunk* bk;
1111 
1112   /* Only used for large blocks: pointer to next larger size.  */
1113   struct malloc_chunk* fd_nextsize; /* double links -- used only if free. */
1114   struct malloc_chunk* bk_nextsize;
1115 };
1116 
1117 
1118 /*
1119    malloc_chunk details:
1120 
1121     (The following includes lightly edited explanations by Colin Plumb.)
1122 
1123     Chunks of memory are maintained using a `boundary tag' method as
1124     described in e.g., Knuth or Standish.  (See the paper by Paul
1125     Wilson ftp://ftp.cs.utexas.edu/pub/garbage/allocsrv.ps for a
1126     survey of such techniques.)  Sizes of free chunks are stored both
1127     in the front of each chunk and at the end.  This makes
1128     consolidating fragmented chunks into bigger chunks very fast.  The
1129     size fields also hold bits representing whether chunks are free or
1130     in use.
1131 
1132     An allocated chunk looks like this:
1133 
1134 
1135     chunk-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1136         |             Size of previous chunk, if allocated            | |
1137         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1138         |             Size of chunk, in bytes                       |M|P|
1139       mem-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1140         |             User data starts here...                          .
1141         .                                                               .
1142         .             (malloc_usable_size() bytes)                      .
1143         .                                                               |
1144 nextchunk-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1145         |             Size of chunk                                     |
1146         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1147 
1148 
1149     Where "chunk" is the front of the chunk for the purpose of most of
1150     the malloc code, but "mem" is the pointer that is returned to the
1151     user.  "Nextchunk" is the beginning of the next contiguous chunk.
1152 
1153     Chunks always begin on even word boundaries, so the mem portion
1154     (which is returned to the user) is also on an even word boundary, and
1155     thus at least double-word aligned.
1156 
1157     Free chunks are stored in circular doubly-linked lists, and look like this:
1158 
1159     chunk-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1160         |             Size of previous chunk                            |
1161         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1162     `head:' |             Size of chunk, in bytes                         |P|
1163       mem-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1164         |             Forward pointer to next chunk in list             |
1165         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1166         |             Back pointer to previous chunk in list            |
1167         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1168         |             Unused space (may be 0 bytes long)                .
1169         .                                                               .
1170         .                                                               |
1171 nextchunk-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1172     `foot:' |             Size of chunk, in bytes                           |
1173         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1174 
1175     The P (PREV_INUSE) bit, stored in the unused low-order bit of the
1176     chunk size (which is always a multiple of two words), is an in-use
1177     bit for the *previous* chunk.  If that bit is *clear*, then the
1178     word before the current chunk size contains the previous chunk
1179     size, and can be used to find the front of the previous chunk.
1180     The very first chunk allocated always has this bit set,
1181     preventing access to non-existent (or non-owned) memory. If
1182     prev_inuse is set for any given chunk, then you CANNOT determine
1183     the size of the previous chunk, and might even get a memory
1184     addressing fault when trying to do so.
1185 
1186     Note that the `foot' of the current chunk is actually represented
1187     as the prev_size of the NEXT chunk. This makes it easier to
1188     deal with alignments etc but can be very confusing when trying
1189     to extend or adapt this code.
1190 
1191     The two exceptions to all this are
1192 
1193      1. The special chunk `top' doesn't bother using the
1194     trailing size field since there is no next contiguous chunk
1195     that would have to index off it. After initialization, `top'
1196     is forced to always exist.  If it would become less than
1197     MINSIZE bytes long, it is replenished.
1198 
1199      2. Chunks allocated via mmap, which have the second-lowest-order
1200     bit M (IS_MMAPPED) set in their size fields.  Because they are
1201     allocated one-by-one, each must contain its own trailing size field.
1202 
1203 */


感想

楽しかったです(白目)
コメントお待ちしております。