ECUってVxWorksの独壇場だと思ってた

コボラーは死ねとかメディアで偉そうに言う人、そのうちC言語しか使えないプログラマーは死ねとかITRON系の組み込み系OSしか使えないプログラマーは死ねと牙を剥いてくるのは時間の問題というかもうそうなってる？

でもBeOSの魂はHAIKUに継がれているので…
Acorn Risc PCに載っていたRISC OSもRaspberry Piで復活したようなもんだし…
それに比べて（いつもの愚痴になるのでこれ以上は省略）。

このアカウントは、notestockで公開設定になっていません。

@hadsn USBディスクからの超漢字のブート、できるディスクとできないディスクがあったように記憶しています。とはいえ、今はxHCI(USB3.0)全盛の時代なのでそもそもUHCI/OHCI非搭載のマシンではどうにも…

@hadsn あと、リファレンスのソースが出ないとやっぱhackしづらいよねというのはあります。某vmxscreenはT-Engine Forumが出しているT-Kernel extensionに入っているドライバコードを改変しているという経緯があるので（ライセンスの問題も面倒臭いです）…実際の製品に使われたコードを改変する方が遥かに生産的ではないか、と。

@hadsn ネットワークとディスプレイはカーネル外のドライバなのでどうにかなるんですが、USBとかディスクに関してはカーネル統合っぽいんですよね（Legacy IDEしか対応しない問題を引きずってるのは多分これが原因）。

美味しそう。自分もインスタントみそ汁に白だしをちょいと入れるのが気に入ってる…

@hadsn 仮想NICはVMware側の問題なので、これを何とかする政治力をPMCには発揮して頂きたいのですが（厳しいだろうけど）、vmxscreenなる怪しいドライバを使わないで済むようVMware SVGA IIないしBochs BGAくらいのドライバは入れてほしいですし、個人的にはvirtioとか欲しいんですよね…全ソースの公開はしなくても良いので、せめてカーネル/ドライバ回りくらいはユーザがhackできる余地を作って欲しいところ。とはいえ、あの惨状だと公開したところで状況は何も変わらない可能性の方が高いのかなー…

IPv4の終焉を見て、Disable IPv4 support. (2018/04/01) https://marc.info/?l=openbsd-cvs&m=152256582629837&w=2 を思い出した。
自宅環境のIPv6対応とか、実はこれを見て慌てて注力したんだけど…エイプリルフールだった、んだよね？このメールって…？？

このアカウントは、notestockで公開設定になっていません。

いいじゃん好きでも嫌いでもWindowsはちゃんとWindowsとして扱ってもらえるんだからさあ…
Xで超漢字に関するポストを検索すると、ネタOSだの陰謀論だのの話しか無いという惨状…正直言ってああいう書き込みばかり見てしまうと、ユーザが離れる/寄り付かないというのは当然というか。

さて、どうデバッグしたもんかなー（思いつかないので現実逃避中です）

個人的に、NetBSD/x32（x86_64だけどアドレス幅が32bitに制限されてる）というのを見てみたいんだけど…LinuxでX32 ABI廃止という話が出てしまった以上は「そんなもん要らん」という話になるんだろうなあ。

触ってみなきゃと思いつつ随分時間が経ってしまっているな…（どういう目的に使えば良いかも分からないんだけど）

これだっけ…？QEMUの、さいきょうのm68kマシン（に対応したLinuxのパッチ） https://lwn.net/Articles/850315/

このアカウントは、notestockで公開設定になっていません。

何故ファンクションキーの表示がおかしい…？

当時物のsj3をSlackware上で動作させると動くってことは…（とはいえsj3.c, sjgetchar.cはFUJIMI-IM版/作業中に挿げ替えてる）挿げ替えていないソースのどこかで何かの問題があるってことか。

Slackware-15でのFUJIMI-IM/sj3のビルド、libtermcapが.soしか無いので-static付きだとビルドできない問題がありますね。

こーゆうものこそgdb等のデバッガの出番鴨

inputprocess()へ来ていない、来ているけど何かおかしい、set_guide_line()の中で何かこけてる、辺りか…？

画面下のステータス、WCSJrun(WcMessages[0])による、"ＳＪ３"しか表示されてないってのが気になるところだな。本来ならset_guide_line()で適当な内容が表示されてるはずなんだけど。

ナマのwcsrtombs()呼んでる箇所は二か所あるけど、どうもsj3と関係ない感じがするんだよなあ。というかvfprintf()の中だったら別にどうでも良い気が。

ん－、localeを見たうえでja_JP.SJISでなければEUCで動く、ということになっている割にはなんかちゃんと動いてないっていうのが謎だなあ。ロケールのUTF-8（EUCでない）に反応してる箇所がどこかしらあったりしないか…？

とはいえ、ja_JP.UTF-8であってもEUC-JPの表示で文字化け起こしてもどうにかこうにか動いてほしいという状況にすらなっていないので、もう少し色々調べないとマズい気がする。

というかLC_CTYPE_EUCじゃないから、という理由だったりしませんかね？＞自分

正直言ってこれは完全に「誤魔化し」、汚い手ではあるんだけどね…

内部的にはcurrent_locale = LC_CTYPE_EUCで誤魔化しておかないと破綻するかも。ってことは、現時点ではSJ_read()の時点でUTF-8→EUC-JP変換を仕込まないとマズいのかも。逆にSJ_print()とかその辺の表示部分でEUC-JP→UTF-8変換入れちゃえば良いかな？

そうするとなると、sjgetchar.c()をUCS-4対応してうだうだとかそういう路線で行くのが良いのかな。流石に文字コードが64bitなんて世界は…来ないよね？来ないと良いなあ。

「待て」のできないヒトって最近多いのかなーっていう気がするんだけど、どうなんだろう。赤信号→青信号に切り替わる直前からじりじりと動き出しちゃう車とか、「○○さーん」と呼び出す前にそわそわと動き出しちゃうお客さんとか…

○○だって「待て」はできるのに、ヒトがそれでは…○○未満ではないのかな、というツッコミは多分誰かがどこかでやってそうな気がする。

このアカウントは、notestockで公開設定になっていません。

まあ、sj3のAPIが求める文字コードに最終的には変換するだけなので、その経路がどうであろうと影響は無いはずだよきっとうんおそらく（震え声

あー、wchar_tへの変換を行うこと自体ロケールの影響からは逃れられないのか。それが嫌ならｵﾚｵﾚwchar_tを定義してそっちでやんなって話になる。 https://www.gnu.org/savannah-checkouts/gnu/libiconv/documentation/libiconv-1.17/iconv_open.3.html

QiitaもZennも（これ以降のpostはかき消されている

wc16_str.cを見るに、sj3_iswupper16(), sj3_iswxdigit16()はEUC依存ですね…誰も呼んでいないので実害は無さそうですけど。

そもそもwchar_tの中身がUCS-4(UCS-32)であることも誰も保証してないよね。概ねそうだけど、ってだけで。その辺も考えないと大怪我するんだが…かといっていちいちiconv呼び出して文字コード変換するっていうオーバーヘッドもあるはずなんだよね。イマドキのマシンだと全然気にならないけど、往年の（二桁MHzくらいなクロックの）マシンだと多分「ん？」と思う程度には。

裏でjs動いてるじゃんというツッコミがありそうだけど、要するにHTMLっぽい記法でhtmx.jsの定義する機能を呼び出せるってことでいいんだよな…？
細かいことは https://htmx.org/ を見ろって、amazonのhtmx本のレビューに書いてあった。 https://www.amazon.co.jp/dp/B0C3G9HC24

このアカウントは、notestockで公開設定になっていません。

というかwchar_tが32bitである保証はない（UNIX系では概ね大丈夫、Windowsは16bitらしい）以上、UCS-2でやっちゃう手も無くはないよね。UCS-4な文字を入力できない、という制約が付くだけで。あまり良い話じゃないけど。

wchar16_tのまま進めるなら、UCS-2で処理するという手はあるのかも。

キー入力処理のキモはSJ_read()か。これ、wchar16_tになってるし内部でロケール（というか文字コード）見てなんかやってるけど…UTF-8の解釈追加してiconvでのwchar_t変換入れるとかしないとダメなんだろうなあ。

init_messages()でiconv_open()、得られたcdはsj3全体で使い回し…iconv_close()の呼び出しは不要、でいいかな？eucmessages.cを見るに、
WcMessages[0] = (wchar16_t *) malloc(all_len * sizeof(wchar16_t));
これに対するfree()は無いので。

ぶっちゃけ、今はEUCで、将来はUTF-8で内部を動かすことになると思うんだけど…setlocale()で文字コード設定を拾っといて、iconv()で内部コードから外部のコードに変換する作りで十分って気がする。C localeならUTF-8扱いでも今は問題ない気がするし。

sj3のロケールチェックって、どの程度必要性があるんだろう？別にja以外のロケールだってsj3を動かしてはいけない理由は無いのだし（日本語話者以外にとって意味不明な文字列が表示されるだけなのだし）。おそらくwcstombs(), mbstowcs()の類が正常に動かないから止めるとかそんな理由なんだろうとは思う。

jaかどうかのチェックは不要として、使用する文字コード…EUC, SJIS, UTF-8を取得する目的でロケール情報を取るというのであれば、それは理解できるんだけど。

というか、ロケールの設定に依存しない作りにする方が堅牢なコードになると思うんだけどどうなんだろう？EUCなりUTF-8なりで内部は処理して、APIの出口だってEUCかそれ以外って規定しているなら別にロケールの設定とか要らんはずだし。

ごめん、sj3.h, sj3priv.hの再編は多分無理。SJ3_OBJSでsj3を構築するのに必要な宣言をsj3.hとsj3priv.hに分けてるけど、これ以上まとめようがないような…

ぐちゃぐちゃにしてしまった、sj3.hの改修始めるかー（あまりやりたくない）

サーバーとサーバの表記揺れも修正したいですね（混在してるのを見るとちょっと許せなくなっちゃう身なので）。

「サーバーが死にました。」って何これ？

eucmessages.c、\nnn形式の値をデコードしてEUCな文字列にしてみたけど…どうしましょうかねこれ。UTF-8/wchar_tで書き換えちゃうのが適当なのかどうか。
メッセージが読めないことにはメンテナンスのしようもないし。

make sj3でのwarning、すぐに手に負えそうなのはscreen.cの-Wsometimes-uninitializedくらいかなあ。toroku.cとetc.cの-Wformat-security、eucmessages.cをデコードしないと直しようがない。他のもエイヤで直すと大怪我しそうな奴に見えるし。

久々に緊張感のあるツイートをしてみるなど。

FreeBSDにおいては、RELEASE-8.4まではutmpがあって、それ以降はutmpxのみなのか。
https://man.freebsd.org/cgi/man.cgi?query=utmp&apropos=0&sektion=5&manpath=FreeBSD+8.4-RELEASE&arch=default&format=html

OS間のutmp/utmpxの違いをイイ感じに吸収してくれるライブラリが欲しくなりますね…

utmp, utmpx周り、どうすんのこれ…💢
NetBSD/OpenBSDはおんなじ感じ、Linuxも対応できてるけど…FreeBSD/DragonFlyはまた別系統っていうのはなんなん…？

ヘッダ周りとgetsjrc2()→getsjrc()への修正は要るけど、当時物のsj3(on Vine 2.5)へのバックポートによる動作テストは問題なし。

なるほど、勢い余ったか何かしてioctl(TIOCSCTTY, NULL)を削ってしまったが故に動作がおかしくなっていたと。しかもこれはBSD系では必要というifdefでくくられていたのでLinuxでは見つからなかった問題になる訳か。

login_tty()でこの辺も含めてきれいに面倒を見てくれそうなので、これを使って直すことにする。

sh: can't access tty; job control turned off
netbsd-vm$

NetBSD上でもなんかtty周りの動作が怪しいっぽい。いじりすぎて壊したか…？

NetBSDにおける、LACKOF_SETLOCALEも復活しないといけないかも。LC_CTYPE、$LANG=ja_JP.UTF-8にしても"C"しか返してくれない。NetBSD以外はちゃんと反映してくれるんだけど。

そもそもutmp/utmpx使ってごちゃごちゃやる必要あんのか…？というレベルまで考えないといけない気がするけどどうなんだろう。

（というかFreeBSD/DragonflyBSDにもIUCLCは無い）

NetBSDにIUCLCは無いので、ここは適当に処理しないといけないかも。

FreeBSD/DragonflyBSDは<utmp.h>ではなく<utmpx.h>になってるのでutmpx周りのコードを削ったところは直さないといけない。

NetBSD:
sj3.c: In function 'fixtty':
sj3.c:427:38: error: 'IUCLC' undeclared (first use in this function)
427 | sbuf.c_iflag &= ~(INLCR|IGNCR|ICRNL|IUCLC|IXON);
FreeBSD, DragonFlyBSD:
./sj2.h:60:10: fatal error: 'utmp.h' file not found
#include <utmp.h>

意外に通らなくなっちゃってますね、コンパイル…

setpgid, getpgid, setpgrp, getpgrp - プロセスグループの設定/取得を行う
https://manpages.ubuntu.com/manpages/focal/ja/man2/getpgrp.2.html
tcsetpgrp — set foreground process group ID
https://man.openbsd.org/tcsetpgrp.3
tty, cua — general terminal interface
https://man.openbsd.org/tty.4

プロセスグループとttyの設定に何か不備があるのでOpenBSD上でのsj3の動作が思わしくない、そう考えるのが良いのかな

とはいえ、__sony_newsの掃除については今まで以上に注意が要るので簡単にはいかないかも。

とりあえずSVR4とLACKOF_SETLOCALEに関しては削除。sj_sysvdef.hはこれで消せるようになるはずなんだけど、ちょっとまだ残してる。次は__sony_newsを掃除しないと。

「CDドライブが故障したくらいでいちいちバラすのは手間ですね。増設しちゃいましょう。」

増設して対応できちゃうとか、凄いんですけど…

SONY NETJUKEをハックする (2022/8/15) https://zenn.dev/mctek/articles/922c7b8281bae3

このアカウントは、notestockで公開設定になっていません。

とはいえこれを整理したからと言って、OpenBSD上でsj3越しにbashなりshなりを起動した際に表示される警告が消える訳じゃないんだけど。

sj3のコード、setsid()が無い場合は/dev/ttyに対しioctl(TIOCNOTTY)発行するんだけど…もうイマドキsetsid()が使えないという環境は無いだろうから、Linux同様シンプルにsetsid()することにしますね。

uaa@framboise:~/z/sj3$ SHELL="/bin/sh" ./sj3
SJ3 Version 2.09C (sjis/euc version)
Fri Feb 23 19:31:47 JST 1996
Copyright (c) 1990-1996 Sony Corporation
All Rights Reserved
Warning Сؤ΀܂˼ǔޤ
Jsh[uaa on sj3]: No controlling tty (open /dev/tty: Device not configured)
Jsh[uaa on sj3]: warning: won't have full job control
framboise$

/usr/local/bin/bashだとよく分からないけど、/bin/shだとなんか分かる気がする。でも分からないけど。

自分とこのdevブランチにあるFUJIMI-IM/sj3なんだけど…OpenBSD上でsj3(tty client)を動かすとなんかエラーメッセージがちゃんと見えるのが謎。画面下のステータスラインはEUCで来ているの（で化けるの）に、なぜエラーメッセージをUTF-8な日本語で表示する…？どこかでUTF-8への変換なりUTF-8でのメッセージを持っていたりする？？

（USBストレージからのブートにも限界はあるし、そっちはそっちでOHCI/UHCI/EHCI→xHCI対応が要るし。）

（Legacy IDE→PCI-IDE→AHCI→NVMeに追従できないだけでPC/AT互換機上のOSは動かなくなる…と、都内某所の方角を眺めながら呟いてみよう。ああ、今はBIOSじゃなくUEFIだからその対応も要るか。）

古いドライバのコード、メンテ出来なくなったらもう切ってくしかないよな…ISA系とかばっさり、PCIですら切るものが色々出て来そう。

Linux Ethernet-HOWTOで、3Comの買ってはいけないチップが書いてあったよなーという記憶があったんだけど、3c501か。 http://archive.linux.or.jp/JF/JFdocs/Ethernet-HOWTO-5.html

errataに関する情報が取れないと、イマドキのデバイスは怖くてドライバ書けないですよ。NDA結べば情報とれるっていうならまだマシで、そんな情報すら取れないのが普通だし…（だからLinuxや*BSDのコードを見るしか無くなる）

このアカウントは、notestockで公開設定になっていません。

ちょっと目的を見誤りそうだな。今日は一旦作業を止めて、明日以降に回そう…

AT&T UNIX System V Release 4を試用する (2022-08-07)
https://debslink.hatenadiary.jp/entry/20220807/1659798257

うーん、そこまで遡る必要が（自分にとって）今あるのかどうか…（悩

というか、Am79C970AですらNICの認識をできないとなると…何なら認識してくれるんだろうか。NE2000か3C905って話があるんだけど（だとしたらVirtualBox/VMwareでなく、QEMUでやれって話にならんか…？） https://forum.vcfed.org/index.php?threads/unix-for-a-486.35335/

OmniOS(CE)、/sbin/haltじゃなく/usr/sbin/haltですと…？！

Kindleでも買えるらしい
はじめてでも安心 コスプレ入門 (2011/11/23) https://www.amazon.co.jp/dp/4274068617

オッサンはAgon(eZ80)みたいなネオレトロなハードとか、マイコンで遊んでなよとか言われそう…

とはいえ、仕様書を見たら見たで頭抱えそう。昔よりも今のデバイスの方がさらに複雑怪奇になってるだろうし。

あ゛ー、SoCのレジスタ叩きたい！（ちょっと禁断症状出てる）

今のお仕事って（お察しください）なんですけど、扱ってる品物によっては情報を持ったヒトがお店にやって来るなんてこともあるので…ほんと扱いが違うよねーって思いました。まあ、扱っている品物が品物なのと、業界がそーゆうところ（文化？）というのはあるんでしょうけど。

高品質なドライバを書きたいなら、デバイスの製造元に勤めるとか入り込むしかないというのが自分の経験上言えることかなあ。
サードパーティーやってると、製造元からの情報提供には限界がある（というかほぼ無いことの方が多かった）以上、Linuxとか*BSDとかのコードを参考にするなどして劣化コピーを作るしかないというのが…

UNIXを教科書読んできちんと勉強したって記憶が…ないｗ
Run Run Linuxでインストールして、あとはいじりながらという気が…（なのできちんとしたUNIXのプログラミング作法、実は知らないんですよ、google頼みでコードいじってます）

これは…確かに人によっては必要になるのかも。相当ニッチな領域だけど。「ＢＳＤ系ＵＮＩＸシステムなどからＳＶＲ４に移行したシステムプログラムにＳＴＲＥＡＭＳに関する詳細で深い知識を提供する実践的参考書。」

詳解ＵＮＩＸネットワークプログラミング （ＡＤＤＩＳＯＮ−ＷＥＳＬＥＹプロフェッショナルコンピューティングシリーズ） (1995.10発行) https://honto.jp/netstore/pd-book_01218612.html

ほうほう。「ＮＥＣ ＥＷＳ４８００シリーズ対応、ＳＶＲ４．２の入門書。歴史的な解説や機能の説明から、日常の操作、システム管理・運用まで、基本をていねいに解説する。必要や興味に応じた読み方ができる。」

ＵＮＩＸ ＳＶＲ４．２システムガイド (1994.5発行) https://honto.jp/netstore/pd-book_01060209.html

すごいなあ。「いまやＵＮＩＸはＳＶＲ４系が主流。しかし、長年ＢＳＤ系ＵＮＩＸを使い続けたユーザーには、移行に対する戸惑いとためらいがあるはず。そんな悩みを一挙に解消してくれるガイド。」

ＢＳＤ ＴＯ ＳＶＲ４移行のための徹底ガイド （Ａｓｃｉｉ ｂｏｏｋｓ） (1995.7発行) https://honto.jp/netstore/pd-book_01207036.html

自分が大学1年（1994～1995年）の頃、サーバ構築はSVR4で決まりでしょ、みたいな空気があったような気がしたんだけど…あれから30年。SVR4の影も形もなくなるくらいLinux一色になってしまったよなあ。

NetBSD/SONY-NEWSって、SONYの人達はどれくらい協力してくれたんだろう？LUNA向けの移植は結構OMRONの人達が協力的なように見えるし、Wnnとかもまあ積極的なのかなーって気がするけど（※根拠なしの個人の印象です）。PlayStation向けのLinuxとか見てると、なんかお塩っぽいのかなーとか思ってしまう。実際どうなんだろうね？

なんかあれだよねー、こういう古いコードをいじるときのために当時の環境がそっくりそのまま残っていて自由にアクセスしてね！なんて感じのラボがあったらいいのに。コンピュータ博物館みたいなものが担うんだろうけど…まあ、将来においてそういうのができたらいいねって気はするけど動態保存も難しいだろうし。

SVR4のコードはもう無条件に切るか…とはいえ、__sony_newsの絡む部分については問答無用する訳に行かない箇所があるからそこは要注意なんだけど、ヘッダとかはざっくり行ってもいいかな（どうせ、無いので）。

うーん、sjctype.hの
#ifndef SVR4
#define euctosjis sj3_euctosjis
#define sjistoeuc sj3_sjistoeuc
#endif
って、これ雑すぎないか？

流石にSolarisの血を引いているだけあって、/usr/include/xti.hにt_open()他TLI/XTIの定義がある。OmniOS CEにbuild-essential突っ込んだだけでこうだから…ああ、sys/euc.hもある。

売り物の環境(Solaris)なんかだとSYSVが定義されているのかなあ。なんとなく、SVR4なコードもばっさり要らないと切っても良い気がするんだけど。（NEWS-OSにBSD系とSVR4系の二つがあるという理由でこんなコードになってるんじゃないかという気がしてる）

#define __GXX_ABI_VERSION 1017
#define __GCC_HAVE_DWARF2_CFI_ASM 1
#define __DEC_EVAL_METHOD__ 2
#define __VERSION__ "12.3.0"
#define __GCC_CONSTRUCTIVE_SIZE 64
#define __STDC_VERSION__ 201710L
#define __GCC_ATOMIC_TEST_AND_SET_TRUEVAL 1
#define __GNUC_PATCHLEVEL__ 0
#define __GCC_DESTRUCTIVE_SIZE 64
uaa@omnios:~$

uaa@omnios:~$ echo |gcc -dM -E -|grep V
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_2 1
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 1
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8 1
#define __FLT_EVAL_METHOD__ 0
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1 1
#define __FLT_EVAL_METHOD_TS_18661_3__ 0
#define __HAVE_SPECULATION_SAFE_VALUE 1
#define __SVR4 1
（つづく）

#ifdef SYSV
#error
#endif
int main(int argc, char *argv[]){return 0;}

OmniOS CE、build-essenialをインストールしてgccで上のコードをビルドしてもエラー出ないんですよね。

ん－、Windows上のVirtualBoxでもなんか安定しない。とりあえずCPUを1個とすると起動するけど。なんなんだろう。

Linux上のQEMU/KVMだとなんか動かないことがあるんだけどOmniOS CE…Windows上のVirtualBoxでやるか…

ん－、VMwareじゃなかったVirtualBox上に一旦インストールして、v2vするか…？

https://gist.github.com/sjorge/4319f87f6eebc1540c91
https://blackdot.be/2014/09/omnios-and-serial-console/
https://wiki.freebsd.org/bhyve/OmniOS

…地味にめんどい？

OmniOS CEを落として何をしようとしていたんだっけ自分。多分sys/euc.hの有無とかその辺の確認という気がするけど。

そもそもこれ、シリアルコンソール越しに動かせるようインストールするとかできるはず…だよねえ？

（情報ありがとうございます）

infocmpが現在使用中の端末に関する情報、infotocapがterminfoを解読してくれるものということになるか…tgetent()の説明によればterminfo使っててもtermcap使っているかのようにエミュレートしてくれるとある。

このアカウントは、notestockで公開設定になっていません。

Emacsを起動しようとしたらtermcapが見付からないと言われる 2007-07-01 https://kuenishi.hatenadiary.jp/entry/20070701/1183229763

確かに/usr/share/terminfoにまとまってるけど…バイナリじゃんこれ。どう読むんだろう。

あー、termcapって端末向けに「こういうの送って初期化しますからねー」って情報をまとめただけの物なので、これ自体が何かをする訳じゃないのか（端末が何かをするので）。なのでlibcursesを見たところでi1だのisだのの二モニックしか書かれてないのは当然か。定義方法だけあれば良いんだし、と。

https://android.googlesource.com/platform/external/ncurses/+/refs/heads/llvm-r416183/include/Caps#796
リセット文字列がr1, r2, r3とあって、r2が無ければrsが参照される。
r3が無ければi2がr3として扱われる。SystemVにおいてはisがi2となる…という理解で良いのかな。

termcapを見るに、wyseの端末はi1もi2もisもあるな。

https://nxmnpg.lemoda.net/ja/5/termcap の説明では、
init_1string i1 初期化文字列
init_2string is 初期化文字列
init_3string i3 初期化文字列
termcap_init2 i2 2番目の初期化文字列

どれがどの順番（どういう優先度）で動いてるかが謎だな。

とはいえ、mbstowcs()、sj3内部のwchar16_t使う奴じゃなくシステムのロケールを反映するwchar_tの方に置き換えたいという可能性もあるから…あんまりいじらない方が良いのかなあ。

sj3、とりあえずいじれるだけコードをいじってる版（PRしていいかどうか分からない版）は https://github.com/jg1uaa/sj3/tree/dev で作業中。

今のところfix, sj3, sj3-ansiブランチを統合して、TLIのコードを抜いた内容になってる。できればSVR4も外したいんだけど、その時点でmbstowcs()絡みの問題にぶち当たったところ（これもSVR4の有無で変わるので）。

wchar16.hにあるmbstowcs()→sj3_mbstowcs()の類、これdefineせずに直接呼ぶ方が良いんじゃないかなあ。<stdlib.h>にあるmbstowcs()を呼んでるのか、sj3側呼んでるのか全然分かんなくなるんだけど。

とりあえず、ヘッダ周りは「しくじった方」で作業進めちゃいます。

あー、しくじったかも。
Google code版のSJ3、kanakan.h, server.h, sj3.h, sj3dic.h, sj_func.hの5つのヘッダに必要な関数を書いていたみたいだけど…sj3.hを魔改造＋sj3priv.hを新設してしまったのでどこかで再編しないといけない。

CFLAGS="${CFLAGS} -g -Wall -Wno-pointer-sign -Wno-unused-parameter"

PR投げる用に、fix, sj3, sj3-ansiにブランチ分けてるけど、なんかこれ統合したのをいっちょ作っといた方が良い気がしてる。ていうか統合したのをPRで投げちゃった方が良いのかな（結構な量になるので実はセクションごとに分けてた）