xlxdとかのリフレクタとかならSTREAMS使って実装とかそういうのは面白いのかもしれない（とはいえ動く環境が限られてくる）。とはいえ、マイナーな（と書くと失礼かもしれないけど敢えて書く）APIで実装した場合はその後のメンテナンスできる人間が居るのかとかAPI自体の寿命によりソフトウェアも道連れにとかなってしまうので、よほどの強い理由が無い限りは避けたいよねえ。

ああ、STREAMSの上にSocketとTLI(/XLI)が載るのか。https://ja.wikipedia.org/wiki/Transport_Layer_Interface#XTI/TLI_%E3%81%A8%E3%82%BD%E3%82%B1%E3%83%83%E3%83%88%E3%81%AE%E6%AF%94%E8%BC%83
https://ja.wikipedia.org/wiki/STREAMS

OpenSS7のコード、2020年くらいのパッケージは出てるみたいだけどコード自体はあんまりメンテされていない（メンテが不要なくらい枯れてる？）気がする。 https://github.com/openss7/openss7

STREAMS vs. Sockets Performance Comparison for UDP (June 16, 2007) http://www.openss7.org/papers/strinet/testresults.pdf
STREAMS (TLI/XTIの類?)はSocket経由よりも速いぜ、ということらしいけど… http://www.openss7.org/papers/strinet/testresults.pdf

1988年くらいのUNIX事情ということになるんだろうか、「ラップトップUNIX」なるキーワードで、socket/TLI周りの話などちょっとした文章があるようなんだけど。 https://ipsj.ixsq.nii.ac.jp/ej/?action=pages_view_main&active_action=repository_view_main_item_snippet&all=%E3%83%A9%E3%83%83%E3%83%97%E3%83%88%E3%83%83%E3%83%97unix&count=20&order=0&pn=1&st=1&page_id=13&block_id=8

NEWS-OSの時代においては、BSDかSystemVかといった争いがかなり激しかったので、おそらくネットワーク周りもBSD socketかSystemV TLIの両対応にしておく必要があったのではないか、という想像をしている。

現在においては、BSD socketが使えれば大概のOSで動くじゃないの、というくらいBSD socketが普及しているけれど（自分もTLIなんて今回の件で初めて知った）。

Transport Interfaces Programming Guide (PDF) https://docs.oracle.com/cd/E19620-01/805-4041/805-4041.pdf (Oct. 1998)

Transport Layer Interface - Trans FX (band) https://ja.wiki5.ru/wiki/Transport_Layer_Interface から、SolarisおよびLinuxで動作するクライアントサーバーアプリケーションの例 https://gim.org.pl/uczelnia/Network-Programming/7.XTI_TLI/
ということでLinuxでもTLIは使えるらしいけど…なんかリンクするライブラリとかの検出が面倒そう。

TLI(Transport Layer Interface) https://ja.wikipedia.org/wiki/Transport_Layer_Interface

要するにsocket()の代わりにTCP/IPを喋らせる手段っぽいけど…要る？

でも、イマドキのUNIXなら*BSD/Linux寄りのコードでもそれなりに動いちゃうような気がするんだけど（そもそも*BSD/Linux寄りってどういう意味だよとツッコまれそうだが）。

手っ取り早くSVR4環境を用意するなら、illumos持ってくるしかない？

※romaji.c, screen.cの修正量が多くてちょっと現実逃避してます

プルリクエスト、マージされてナンボ（成果）でしょという評価基準だと…MMDVMHostのIPv6対応くらいしか成果として書けるものが無いってことになるか。

あっちの界隈でそういうものの見方をしてうだうだ言う人がどの程度いるのかは知らないし知りたくもないけど、厄介な人達は既にそういう物差しで見ていることは分かっているので（そういう視線はたまに感じています）…厄介を黙らせるための「成果」を作らないといけないのかなあ。本意じゃないんだけど。

xlxdなるDMRリフレクタ（中継サーバと思って下さい）とmrefdなるM17リフレクタを動かしているのだけど、どうもこれらを統合したxlxdの進化版であるurfdなるものがあると今知った。 https://github.com/nostar/urfd

xlxd、IPv6対応パッチのPRを出していて３年以上放置されてる（xlxdの更新に一応追従はさせてる）んだけど、なんかパッチを捨ててurfdへ移行した方が良いのかなーって気分になってる。

（捨てずに移行しても良いんだろうけど、マージする気の無いものを出し続けるのもそろそろ嫌になってきたし）

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

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

SJ3_OBJS, SJ3DIC_OBJS, SJ3MKDIC_OBJS, SJ3STAT_OBJS, SJ3RKCV_OBJSでこれなので、KANAKAN_OBJSの状況を考えると頭が痛いです。かな漢字変換の要となる部分なんだろうし、ヘンにいじるとおかしなことを引き起こしそうで…

とはいえ、sj3_rkconv_mb()が外部から呼ばれている形跡はなく、sj3_rkconv_mb()でキャストされた状態で呼ばれているため、型が何であろうと問題は無いはず…内部の問題、で片付く話かも。

fix branchの時はmake時にimplicitうんぬんで表示された関数に対するプロトタイプ宣言をその都度記載していたんですが、その関数が記述されたファイルの中における関数の出現順もきちんと意識したいしいちいちその都度追加するのも面倒臭い→だったらもうそのファイルに記された関数を全てプロトタイプ宣言としてsj3.hに書いちゃおうぜ、という方向に変えてます（流石にstaticな関数は書きませんけど）。

これ、本気で面倒臭くてぶん投げたくなるくらい面倒なんですが、なんか妙なコードも炙り出せているのでやる価値は（ちょっとだけ）ある感じです。

拝啓　過去の自分殿
https://github.com/FUJIMI-IM/sj3/pull/10/commits/91c5c87e74a2a8e8908dcc66c3142b1383842f23#diff-060563743bc31971162a6d5456d3644dc7d9dd834b0759a1b56e631cef167668R1064
この修正部分、何故オリジナルではunsigned char *となっているのに貴方はwchar16_t *に変更しているのか、理由を教えて頂けませんか？
別にunsigned char *で問題無いのではないでしょうか。mbstowcsのmbs側の引数になるため、wchar16とする理由は薄いように思われますが。

…という訳で修正版のPR後で投げます
（多分、sj3_rkconv_w16()のプロトタイプ宣言に引っ張られたのかも）

SK3RKCV_OBJS (rk_conv.o, sj3_rkcv.o, wc16_str.o)は以前の修正を仮置きするだけ（多分どこかでPR投げてるはずなので）に留めとく

とりあえずeucmessage.oまではどうにか…

edit.c: In function ‘exec_edit’:
edit.c:432:25: warning: this ‘for’ clause does not guard... [-Wmisleading-indentation]
432 | for (i = 0 ; i < num && Zcol >= 1 ; i ++)
| ^~~
edit.c:434:33: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the ‘for’
434 | Zcol -= 1;
| ^~~~

このwarningは今はちょっと置いとく。多分バグな気がするけど。