大晦日の深夜に申請しちゃった三海通の試験、20日に工学/法規、21日に英語/電気通信術ということで…もうそんな時期なのかと。工学は一陸技による免除を使い、英語は次回以降とするにしても、残った二科目がどちらも難しい。

電気通信術、受話はともかく送話は正しいNATOフォネティックコードを言えば良いだけとはいえアマチュア無線上がりだとItaly（正しくはIndia）だのJapan（正しくはJuliet）だのといった正しくない言い回しをうっかり言いそうになるのが非常に怖いです。直接印刷電信は普段キーボードに触れて文字を入力していれば何とかなるらしいですが、電気通信術の試験方法にある鍵盤配列は、日本工業規格（Ｘ6002）「情報処理系けん盤配列」によるもの（いわゆるjp106キーボード）であるという点が自分にとって厄介です。仕事場ではjp106、家ではus101なので対応はできると思いますが…多分できるんじゃないかなあ、記号類の入力が試験に出てこないことを祈るしかないかも。

法規は、平成27(2015)年9月期〜令和6(2024)年9月期の過去問に幾度か目を通してはいますが、いやらしい引っ掛けによる失点をどこまで防げるかが合否を分けそうな気がします。あと、国際法規がかなり広い範囲から出てくるので（自分の見た範囲の過去問では、やさしく学ぶ第三級海上無線通信士試験だけでは足りない印象があります）これもヘンなのが出てこないようお祈りです。四海通の方がまだ素直に見えるとはいえ、こちらもこちらでしれっと引っ掛けてきますよね…

まあ今回落としたとしても、9月期にまた試験場へ行くことになるのでその時に拾えば良いと考えてはいます。面倒なので英語だけで済ませたいですけど。

こんな状況にありながら、電気通信術、折角なので電信のリハビリをしてみようかなとか考えていたりします。LCWO、Koch法によるモールスの習得ということでちょっと触ってみましたが、20WPM（実効15WPM）の2文字(K, M)ですらロクに取れない…マトモにできるようになるには相当な時間が必要そうです。

押し入れに仕舞っていた電鍵達も引っ張り出して簡単に叩いてみましたが、HK-705旧モデルと常熟電訊器材廠制造のもの(K4)を比べるに、自分は手首を机の上に置いたままで打てるK4の方が打ち易いと思いました。とはいえ、手首を机の上に置く米式電鍵は和文には不利という話もあり、本格的にやるならエレキーもしくはもう少しグレードの高い電鍵の導入も考えておかないといけないのかもしれません。考えるのは三海通が取れた後にしたいところですが、新品で入手可能なハイモンド・エレクトロ社の最上位機種がHK-704しかないという現状を見るに（業務用高精度電鍵であるHK-807、防衛庁でも使われていたと言われるHK-808、大理石台のHK-702、どれも販売終了しています）、のんびりしている余裕は無いのかもしれません。55.9kg(23:15)

bzuncomp（昨日作ったやつ）のテストとして、OpenBSDの/usr/sbinにあるファイルを片っ端から$(BD)/etc/bzcompを使って圧縮→bzuncompで展開→元のファイルと比較、を考えていたのですが…bzcomp自体が何故かSIGSEGVで落ちてしまいます。どうやら、/usr/sbinにあるファイルを書き込み禁止のまま食わせたためにchar *strerror()でエラーメッセージを表示させる際に問題が起こったということで、直します。

これに加え、超漢字開発環境自体がgcc-2.95辺りの時代のC言語で書かれているので、イマドキのコンパイラだと警告は当然としてもエラーを起こしてビルドできない状況だったりします。databox.cは03-Feb-2009にあるdiffを使うとして、bzcomp.cの他comp.h, mkbtf.cについても手を入れないと駄目な時代になっています。mkbtf.c、gccでは大丈夫そうですがclangではmain()の引数が(void)か(int, char**)でないと駄目です（たとえば（unsigned int, unsigned char**)はエラーになります）。

bzuncompも、memcpy()みたいなことをする処理を見直しています。おそらく心配は要らないのでしょうが、最適化により出力結果が変わるかもしれないというのも嫌なので…流石にmemcpy()のままで良い部分まで置き換えちゃうのはやり過ぎかもしれませんが（#include <string.h>を削れるなーと思ったからです）。56.2kg(23:05)

$(BD)/tool/tool/bzcomp.c（実行プログラムの圧縮）があるのに、圧縮されたものを復元する手段が無いのででっち上げた話(06-Dec-2023)の続き。

i386-elfなbzuncomp.oをlibg.aから取ってくるのは流石に使い勝手が悪いので、$(BD)/tool/tool/src/comp.hにある圧縮部分の本体を読み解いてこれに対応するコードを書くことにしました。comp.hの「P (1 〜 4095) バイト前の位置から (L + 1) バイトを出力」に対する処理、これはmemcpy()を使っちゃ駄目ですし、memmove()でも正しい結果が出ないという…これに気付くのに結構時間を使ってしまいました。main.cについては何も手を加えずに使い回しています。

とりあえずファイルを一つ二つ展開してオリジナルのbzuncomp.oを使用した場合と結果が変わらないことを確認した程度なので、何らかの問題が残っている可能性はあります。また、こちらで実装したbz_uncompress()は

• 展開の際にエラーが発生した場合は、-1を戻り値とする
• dst = NULLの場合はdlenの値を無視し、展開後のサイズを戻り値とする
• dst != NULLの場合、展開後のサイズがdlenを越えた場合はエラーとする

という作りにしていますが、ここは異なるかもしれません。本当はきちんと調べてから作るべきなのでしょうが、まずは展開ができれば十分ですし、オリジナルに動作を合わせるのはその必要が生じた際に行えば良いと考えています。56.2kg(23:15)

09-Mar-2025補足：bzuncomp.cのmemcpy()回りを少し見直しました。詳細は09-Mar-2025を参照。

動作確認がてらFreeCOMのビルドを。残っていたOpenWatcomの修正を行った後に*BSDへの対応を追加してみたものの、動作するcommand.comはまだ得られていません。

FreeCOMのビルドに使うCコンパイラは

• DOS用のバイナリを生成するためのOpenWatcom（ia16-elf-gcc等他のコンパイラも使用できるようです）
• FreeCOMのビルドに使用するツールを生成するためのホストOS用コンパイラ

があり、LinuxにおいてはDOS/ホストOS共にOpenWatcomを使います。一方、OSXにおいてはDOS向けのOpenWatcomに加えホスト向けにclangを使います。*BSDについてはOSXと同様の対応を行うことにより、途中で生成されるcommand.exeまではLinuxと同様のバイナリが得られることを確認しています。ここから先、何らかの加工を行った後に出来上がるcommand.comが動かないので、何らかの加工に問題があるだろうということで調べているところです。

とはいえFreeCOMはまだ良い方で、FreeDOSカーネルはDOS/ホスト共にOpenWatcomで通すことを前提としているようです。これを*BSD上でビルドできるようにするにはどうしたものか…OSX上でFreeCOMのビルドを行うのと同様に、DOS/ホスト側で使用するコンパイラをきちんと分離するのが現実的な解となるのでしょうか。

生成AIを使用したコーディングが話題になっているので、10-Feb-2025の試作品をこんな感じのプロンプトにしてGensparkのClaude-3.7 Sonnetに食わせてみました。

得られた結果はなかなか興味深いです。文字列はargv[0]で与えると指示したにも関わらずargv[1]で指定することになっていたり、環境変数PATHを使用してサーチする場合もrealpath()を通しているとか。それはともかく、得られたコードのコンパイルがきちんと通り（エラーが出ないだけでなくwarningも出ない）、実行したら（argv[0]についてはともかく）動いたのが一番の驚きです。

生成AIによりプログラマーが不要になるかどうかは、まだ分かりません。現時点ではCコンパイラの登場した初期…Cのコードが適切にアセンブラに翻訳されたかどうかを見守りながらCのコードを書く、そんな時期と似ているように思われます。プロトタイプをざっくり作ったり、コードをレビューしてもらったり、より良いコードを書くためのアイデアを得るための相談相手として使うには、良いのかもしれません。

AI主体でコードを書く日が遠くない未来にやってきたとしても、コードが適切に書かれているか/動作するかを判断するヒトはおそらく必要とされるのではないかと思いますが…どうでしょうかね？56.8kg(24:05)