inside
buf write 1b58ac0 f0 00000000 00000200 -- 00000200 00004600 -- 00004800
0 1 1 200 200
write 01b58ac0 -- f0 00000200 00004000
outside
append
write 01b58ac0 -- eb 00000000 00000200
最後の方に何書いてるのか、って話になりそう。
NetBSDでのmformatの実行結果、なんかこれ地味にマズくないか？
00167fd0 02 00 00 00 01 00 00 00 d0 65 0e ff 7f 7f 00 00 |.........e......|
00167fe0 e0 69 0e ff 7f 7f 00 00 c0 61 0e ff 7f 7f 00 00 |.i.......a......|
00167ff0 2f 75 73 72 2f 73 68 61 72 65 2f 6c 6f 63 61 6c |/usr/share/local|
00168000
なんか触っちゃいけないメモリを触ってるのか、あるいは初期化してないのか…すごく嫌な予感がする。
えーー？！
- ゴミあり
DragonFlyBSD(gcc)
FreeBSD(clang, gcc)
NetBSD(clang, gcc)
Linux(clang)
OpenBSD(clang)
- ゴミなし
Linux(clang)
OpenBSD(egcc)
openbsd-clang.img
00167ff0 68 37 00 00 22 00 0b 00 e0 ad 0a 00 00 00 00 00 |h7.."...........|
00168000
openbsd-egcc.img
*
00168000
uaa@framboise:/export$
linux-clang16.img
*
00168000
linux-gcc.img
00167ff0 50 bf fb 75 fc 7f 00 00 00 00 00 00 00 00 00 00 |P..u............|
00168000
netbsd-clang.img
00167ff0 50 73 a2 ff 7f 7f 00 00 90 72 a2 ff 7f 7f 00 00 |Ps.......r......|
00168000
netbsd-gcc.img
00167ff0 2f 75 73 72 2f 73 68 61 72 65 2f 6c 6f 63 61 6c |/usr/share/local|
00168000
uaa@framboise:/export$ for i in *.img;do echo $i ;hexdump -C $i |tail -n2;done
dragonfly-gcc.img
00167ff0 30 c8 df ff ff 7f 00 00 02 00 00 00 02 00 00 00 |0...............|
00168000
freebsd-clang.img
00167ff0 f4 37 e8 00 00 00 00 00 2b 90 a7 67 08 00 00 00 |.7......+..g....|
00168000
freebsd-gcc.img
00167ff0 48 6b 82 20 00 00 00 00 00 00 00 00 00 00 00 00 |Hk. ............|
00168000
mtools-4.0.47に上げても、format -i a.bin -f 1440 -Cでファイルの最後がゴミになる件…OpenBSDでもegccなら問題なく、cc(clang)で発生することが分かった。他のプラットフォームでもgcc/clangで問題が起こるかどうか、探ってみることにする。
screen.cのspaceR(Guide)→printR(tmp)→SJ_print()→printf()で表示か。SJ_write()に依らずに表示するなら確かに妙なことが起こるのは確かなんだが…何故別系統なのかとか、SJ_write()以外にどこに何を表示するコードがあるかを考えないといけないな。
print_guide_line()で表示してる、これはSJ_write()を通してないように見えるが…
ふむ、gdbでonwinchを引っかけてトレースしてみるに、きちんとステータス行を表示するものの、その後0x0cを表示して消すという動きになってる。どうすんだこれ。
Debian-12でもclang-16を使えるので、これを入れてOpenDHTのビルドを試みたけどusleep()周りでこける以外はtools/の生成は問題なし。
…ってことは、OpenBSD特有の問題なのかな。-fvisibility=hiddenの話。
Fonts66コンプリートパック／109書体
3/14まで特売やってます。\2980。
https://pcshop.vector.co.jp/promo/catalogue/fonts66/
幾度か特売をやってることがあり、その度にチャンスを逃していたんですが…とうとう掴めました。
欲しいものがあってもとんでもなく高価になるとか、お金積めば動いてくれる人のアテがないとか、とにかくなんかツラいですこの世の中って…（自分の努力て手に入るもので我慢しな、なんでしょうかね…それで満足すれば苦労はしない）。
Unihan-2.txtによる補正と、一部記号類を強引に置き換えて多少は読めるようになったけど（無→无は日本人として違和感あるけどしゃーない）、まだ完全な置き換えにはなってない。「売」「拝」が出てない。
JISで書かれたものをGB2312でどこまで表示できるか試しちゃみたんだが…微妙だな…
kakasi使ってひらがなの量を増やす（漢字を減らす）というのが良さそうに思えるけど、それでもどこまで迫れるだろう。
あとは、漢字の類似度に合わせて強引な置き換えとかそういうのを考えないといけないけど、そういうのってもう誰かがやってたりするよね？（やっててほしい）
Unicode、CJK漢字を統合していることが非難されているという事情はあるものの…逆にこれを利用して、JISコードで書かれたものをある程度GB2312とかKS C 5601で表現するという目的に利用することができるのではないか？と考えている（テーブルを作れば良いだけなので試すのはそんなに苦労しないはず？？）
VMware Player上のRaspberry Pi Desktopだと動いちゃいるみたい。fprintfの引数がおかしいと怒られたけど。
uaa@emeraude:~$ echo "かな 漢字 ヘンカン" |kakasi -iutf8 -KH -JH
かな かんじ へんかん
uaa@emeraude:~$
kakasi、ちゃんとUTF-8対応してるじゃん…（多分-iutfみたいに間違ってたオプション指定してたんじゃないのー？＞自分）
find()だとイテレータを返してしまうし（end()のチェックをすれば良いのか）、単に存在チェックするのにat()＋try～catchだと大袈裟だ、ということでcontains()なんだけどC++20ってのがなあ。 https://cpprefjp.github.io/reference/map/map/contains.html
大判焼のことか…（解釈に５秒以上かかった）