FUJIMI版SJ3、元のSJ3が動かない環境で当てずっぽうにやってきたので、元のSJ3が動く現代的な環境でやり直した方が良さそうな気がしている。

@omasanori sj3が動き出しているんですが、如何しますか？ https://github.com/jg1uaa/sj3/tree/dev （今までPR出していたfix, sj3ブランチの内容をすべて含んでいるのと、FreeBSD/DragonFlyBSDのutmpx非対応という制限があります）

@uaa どうしましょうか。オリジナルに戻って必要なパッチを洗い出すか、今のmainブランチを更新していくか、どちらが筋の良い方向性だと思いますか？

@omasanori 自分は置かれた状況に合わせてもがいちゃうので、どちらを選ぶかというのはなかなか決めきれないです。コードの歴史を重視するならオリジナル（のディレクトリ構造）に戻るとして、未来に向けて作り変えていくのであれば今のmainブランチからという気がします。

他の方の意見も聞いてみたいですね…

@uaa @omasanori プログラムのバージョンアップ (コンパイル近代化に限る) という観点からすると、リファレンスとなる当時物の環境を用意して正となる動きを確定する必要があると思います。そしてその次に、現代のコンパイラで警告やエラーにならない記法に書き換え、当時物のコンパイラと現代のコンパイラに記法の互換性がある場合は当時物のコンパイラでコンパイルして同一の動作をするバイナリに仕上がるかを検証し、 (現代では使いようのないコード切除したうえで) 現代のコンパイラでコンパイルして動作を検証する、という過程になるべきかと (四半世紀かけてコツコツやるソースのメンテナンスを巻きでやる感じ)。つまり記法だけ変えた原典 for gcc 2.95 on Linux 2.4と、不要そうなコードを切除した原典 for gcc 13.2 on Linux (それともClang?) のブランチを切っていく感じですかね (現実に即していない正論を言い過ぎて誤射されるパターン)

@hadsn @omasanori
記法だけ変える、というのは多分K&R→ANSIだと思うんですが、ANSI化も地味に厄介です。 戻り値の型が定義されていない関数は無条件でintという扱いにすることもできず（戻り値が無い場合はvoidにしないとエラーになります）、こういうコードの場合

sj_han2zen(c)
unsigned short c;
{
unsigned short cc;
(略)
return(cc);
}

本当に戻り値がintで良いのかという問題があります。そして戻り値の型が不適切な場合はエンバグするとか…（やりましたｗ）。
将来的にはAI様がこの辺の作業を楽にしてくれると期待したいところですが、現状ではまだまだヒトが頑張るしかなさそうです…