Not only is the Internet dead, it's starting to smell really bad.:2021年05月20日分

2021/05/20(Thu)

[わからない] もう何もわからない

そもそもITってのは反復業務には強いけど、予期せぬ緊急事態への即応性なんぞ開発期間がボトルネックになるから皆無って認識を皆が持ってほしいよな、FAXと人力がダサいと思ってる人こそIT音痴だってそろそろ気づこう。 それともデジタル庁から赤紙でスーパープログラマ動員してデスマ従事させたあと戦時徴用船みたいに補償金ですただし特別税100%な!ってやってみる?

すぐに沸いてくるIT後進国!日本にGAFAM *1は生まれない!とぶちあげて気持ちよくなりたがる手合いは無視でいいよ、そういうのに限って毎年のように億人単位の個人情報を漏洩させるFacebookの「完璧目指すよりまず終わらせろ」を名言とか担ぎ上げるダブスタ野郎だし *2

プログラマの美徳とされるものに「手動でやるより何倍もの時間がかかってもプログラムを書いて処理する」ってのがあるけど、裏を返せば「即応性ならいまだ人力の方が勝る」ともいえるんだよな。 いまのIT神話の火付け役の一角であるAmazonだってMechanical Turkみたいなスーパー低お賃金人海戦術部隊なんぞ囲ってるわけでな。

あとCOCOAのバグ放置問題、AppleとGoogleがAPIの利用を一国一組織って制限つけたせいで代替アプリが存在しない状態になってしまった事はもっと失敗の原因として挙げられるべきよ、その分開発者も減るわけで情報共有ができなくなるからね。 もちろん悪意のある偽アプリが蔓延することで社会的混乱を防ぐ意図はわかるんだけど、じゃあそもそもストア審査って何のためにあるんでしたっけって話でな。 ああ審査なんてザルもいいとこでその実は高っかい高っかいショバ代徴収するための名目上の理由したっけウフフ。

さてどうでもいい話はおいといて、滝沢先生が修正したregex(3)のBM法のコード、integer overflowの対策はしてあるなと感心してたが、size_t overflowの方の対策は見過ごしてて草。 まぁ検索文字列長 + 検索対象文字列長がsize_tを超えるってまずありえないのでワイの方がお薬必要なだけな気がしないでもない、途中でヒープ枯渇するなりmmap(2)の制限にひっかかるからな…

あとmatchjump(suffixのmismatchを求めるテーブル)の生成がちょっとややこしいコードなんだけど(pmatchesなんていう一時テーブル用意したり)、普通もっとシンプルなコードだよねぇ。 これでテーブル生成高速化できるとかあるのかな、うーむ読み解かないとならん…

それとBM法を非UTF-8なmultibyte localeでも有効にするため、前に戻ってmultibyteの途中にマッチしてないかを探すAPIをi18n encoding moduleに追加べきなのか相変わらず考えがまとまらない。 問題はISO-2022-JPとかだけどあれもlead byteを探すでなくなくエスケープシーケンスの0x1bを探せば移動量の問題はあるけど可能ではあるし。 でもそもそも検索パターン文字列が完全に変換可能なmultibyteであることって規定あるんだっけ?それこそmultibyteの途中からはじまる検索パターンを指定した場合マッチしなくなるよな、でもregcomp(3)失敗するからいいのか。 パラノイア過ぎる気もするのだがわからないもうなにもわからない日々なのだ。

関係ないけどその過程で思い出したのがnvi-1.81をja_JP.ISO-2022-JP localeで動くようにするのに、どのようにしてモード切替のESCとエスケープシーケンス開始の0x1bを区別するのかという難問。 ちなみにnvi-m17nでは0x1bが入力されてから一定時間経過したらモード切替という苦肉の策だったような記憶がある…

あとnvi-1.81のset fileencodingのバックエンドであるconv.cでのiconv(3)の使い方がアレな件も思い出してしまった、当時そこまでやる時間なかったんだよなぁ。

そもそも人類にiconv(3)は難し過ぎるので、VisualC/C++のfopen("ccs=encoding")みたいな拡張で隠すべきと思ってるんだけどね、それをいったらどっかのドイツ人に鼻で笑われた記憶があるけどまあ一生iconv(3)とダンスしててください。 はっきりいってこの世に正しいiconv(3)の使い方をしてるコードって片手で足りるんじゃねえの感あるゾ。

移植性考えないのならfunopen2(3)とかfopencookie(3)でfopen("ccs=encoding")的なもの実装しちまうのだけど、BSDとglibc以外を考えるとアレ。でも今fmemopen(3)とかopen_memstream(3)のバックエンドとしてこの手の機能必要になってるはずなのだがSolarisあたりどうしてるんだろうな。 もはやOracleのログインパスワードなんか覚えてないのでSolaris11落としてくる気にもならんのだが。

また別の話だけど、先日opensslをgit subtree化する作業をやった後、build releaseは完走するのにbuild release -uでobjを残した状態で再ビルドするとbinutilsのgasのバグ踏んでるのかopensslのasmコードのビルドがコケるので困る。 とりあえずbinutilsを最新にした方が良さそうだ、またやらんとならん作業が増えたやはりワンオペは厳しいねその分何の責任も無いから気楽でいいけど。

*1:G-MAFIAの語呂合わせに巻き込まれるIBMっていま何が本業なのだろう…
*2:まぁTRON陰謀論とか信じるよりはまだマシか…