とりあえず然るべきところにパッチは投げた。あとは裁定を待とう。これが解決しなければ次へ進めないのだし。

振り返ってみるに、

問題の解決に8時間、解決方法はオプション一つ付けるだけ、って…どんだけ時間かけてるのあんた無能？

って言われてもおかしくないよなあ、これ。とはいえ今までこれを誰も言及してないってことは、そういう（展開できない）アーカイブに誰もぶち当たっていないか当たっていたとしてもスルーされていたかのどっちかなのかな。

memmove()
real 0m0.359s
user 0m0.340s
sys 0m0.010s

-DNOMEMCPY
real 0m0.321s
user 0m0.290s
sys 0m0.000s

ふむ、オプション一つ付ければ解決できそうだな。

やっぱ/var/log/messagesに出てるじゃんよ…（確かprintf("%n");辺りもOpenBSDでは禁忌なんだけど、こっちはSIGABRT吐くのでまだ分かりやすい）

Jan 12 20:59:35 framboise unzip: backwards memcpy

])@#@#@#$^&&([0xdfbba234238 21557 55994 4
])@#@#$^&&([0xdfbba234238 21562 21570 9

あー、これ、アレだ。memcpy()の領域が重なるとダメってやつに掛かってる。

#ifndef NOMEMCPY
if ((unsigned)w - d >= e)
/* (this test assumes unsigned comparison) */
{
putchar('[');fflush(stdout);
memcpy(redirSlide + (unsigned)w, redirSlide + d, e);
putchar(']');fflush(stdout);
w += e;
d += e;
}
else /* do it slowly to avoid memcpy() overlap */
#endif /* !NOMEMCPY */

ここのmemcpy()で落ちてる（けどcore吐いてない）

inflate_codes()から戻らない

inflate_dynamic()から帰ってこない

inflate_block()から戻ってきてないな

そうすると、clangで-Wdeprecated-non-prototypeについても関係ないって話にならんか…？

FreeBSD-14.2/amd64(clang-18.1.6)でmake -f unix/Makefile genericでunzip60を野良ビルドしてみたけど問題無し。portsでclang-16.0.6もmake -f unix/Makefile bsd（genericはビルドエラーがでた）を試しているけどこちらも問題無し。

unix/unix.c:1346:5: warning: a function definition without a prototype is deprecated in all versions of C and is not supported in C2x [-Wdeprecated-non-prototype]

-Wdeprecated-non-prototypeの出る箇所は150箇所。これ全部直すのはきついんだけど、場合によってはやるしかないんだろうなあ。

ALL_TARGET、デフォルトはbsdだけどgeneric, generic1, generic2, generic3でもだめ。
linux_noasm, freebsdはgcc縛りになるのでビルド以前の問題。
ん？freebsdがgcc縛り…？

もしかして：K&Rの呪い？

FLAVORなし
cc -c -O2 -pipe -I. -DLARGE_FILE_SUPPORT -DNO_LCHMOD -DUSE_UNSHRINK -DBSD -DSFX -o unix_.o unix/unix.c

FLAVOR=iconv
cc -c -O2 -pipe -I/usr/local/include -I. -DLARGE_FILE_SUPPORT -DNO_LCHMOD -DUSE_UNSHRINK -DUNICODE_SUPPORT -DUNICODE_WCHAR -DUTF8_MAYBE_NATIVE -DNO_WORKING_ISPRINT -DBSD -DSFX -o unix_.o unix/unix.

OpenBSD portsだと、こう。

cc -c -I. -Ibzip2 -DUNIX -O3 -DLARGE_FILE_SUPPORT -DUNICODE_SUPPORT -DUNICODE_WCHAR -DUNICODE_SUPPORT -DUTF8_MAYBE_NATIVE -DHAVE_DIRENT_H -DHAVE_TERMIOS_H -D_MBCS -DSFX -o unix_.o unix/unix.c

Linux上で野良ビルドしたものは問題無し

- OpenBSDのバージョン(7.6/current)は関係ない
- 32bit(i386)/64bit(amd64)も関係ない
- コンパイラ(egcc/clang-16/clang-17)も関係ない

となると、元のロジックの問題という気もするが…Linuxのバイナリパッケージじゃなく野良ビルドでは問題ないのかというのは気にかかるか。

-bash-5.2$ unzip -t GenEiLatin_v2.1.zip
Archive: GenEiLatin_v2.1.zip
testing: GenEiLatin_v2.1/ OK
testing: GenEiLatin_v2.1/GenEiLateGo_v2.ttc OK
testing: GenEiLatin_v2.1/GenEiLateMin_v2.ttc OK
testing: GenEiLatin_v2.1/LICENSE.txt OK
testing: GenEiLatin_v2.1/readme_??????.txt OK
No errors detected in compressed data of GenEiLatin_v2.1.zip.
-bash-5.2$

こっちは問題ないんだけど。

-bash-5.2$ unzip -t GenEiLatin-Separate_v2.1.zip
Archive: GenEiLatin-Separate_v2.1.zip
testing: GenEiLatin-Separate_v2.1/ OK
testing: GenEiLatin-Separate_v2.1/GenEiLateGoN_v2.ttf -bash-5.2$

こんな風に打ち切られてしまう

ん－、OpenBSD-7.6/i386でもGenEiLatin-Separate_v2.1.zipの展開に失敗する。
それにしても、VirtualBox上の32bitゲストってこんなに遅かったっけ？

sftp> get GenEiLatin-Separate_v2.1.zip
Fetching /home/uaa/Downloads/GenEiLatin-Separate_v2.1.zip to GenEiLatin-Separate_v2.1.zip
GenEiLatin-Separate_v2.1.zip 100% 19MB 195.2KB/s 01:39
sftp>

ふむ、GenEiLatin-Separate_v2.1.zip、OpenBSD-current/amd64でも展開に失敗する。

egcc(gcc-8.4.0), clang-17でもダメ。

最初の時点に立ち返らないといけない。distfilesにあるunzip60.tar.gz（オリジナルのアーカイブ）のunix/unxcfg.hを手直しすればmake genericでビルドが通るけど…これでもGenEiLatin-Separate_v2.1.zipの展開ができない。
OpenBSD-7.6/amd64, clang-16での話。

FLAVOR=iconvでもだめ

パッチはシロじゃね？

ん？patch-unix_unxcfg_h patch-unzip_cを適当するだけの状態でもまともに動かないんだけど…

うーん、Linuxのinfo-zip(unzip-6.0)が問題無いとすると、OpenBSD版はパッチがあれこれ入ってるのでこれのどれかが悪さをしている、と考えるのが妥当そう。

OpenBSDのunzip-6.0は展開に失敗するけどDebian-12.9のは問題なかった。何故だ。

源暎ラテゴ/ラテミン、TTC版のportsでも良いんだろうけど…Emacsで源暎ラテゴの詰じゃない方！という時にTTC版だと調整が効かないので、TTF版にしたい。

源暎ラテゴ/ラテミンのTTC版は問題無いんだけど、TTF版、UnZip 6.0だと展開に失敗するんだけど自分とこだけかなあ？ https://okoneya.jp/font/download.html

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