syghの新フラグメント置き場

プログラミングTipsやコード断片の保管場所です。お絵描きもときどき載せます。

MSVC (ユニバーサルCRT) のswprintfのバグ

Visual C++のC Runtime (CRT) ライブラリは、バージョン2015 (14.0) 以降、新しい設計のUniversal CRT (UCRT) を採用するようになり、C/C++標準ライブラリが再実装されました。
その際、かなりの数のバグが混入したのですが*1*2、いまだに修正されていないバグもいくつかあります。

例えば、以下のリファレンスでは、swprintf()WEOFを出力しようとした場合、戻り値はエラーコード-1を返すことが明記されており、サンプルコードでも例示されているのですが、UCRTでは間違った値を返します。

#include <stdio.h>

int main(void)
{
    wchar_t buf[100];
    int len = swprintf(buf, 100, L"%s", L"Hello world");
    printf("wrote %d characters\n", len);
    len = swprintf(buf, 100, L"%s", L"Hello\xffff world");
    // swprintf fails because string contains WEOF (\xffff)
    printf("wrote %d characters\n", len);
}

VC2013までは、11-1が正しく出力されるのですが、VC2015以降では1112が出力されます。
swprintf()系はvswprintf()系を使って実装されており、当然のごとくvswprintf()にも同じバグがあります。

これはWindows 10 21H1の最新版UCRT (ucrtbase.dll, 10.0.19041.789) でも修正されていません。

ちなみにWEOFは "%ProgramFiles(x86)%\Windows Kits\10\Include\10.0.*.0\ucrt\corecrt_wstdio.h" にて以下のように定義されています。

#define WEOF ((wint_t)(0xFFFF))

UCRTは、Windows 10では標準システムコンポーネント扱いとなっており、UCRTを動的リンクしたアプリケーションは、システムディレクトリにインストールされているDLLのほうを必ずロードするようになっています。Windows 8.xおよびそれ以前のバージョンでは、アプリケーションに同梱されているプライベートDLL(ローカルDLL)があればそちらを優先的にロードするようになっています。

UCRTのソースコードWindows SDKに付属しています。インターフェイスはCですが、内部実装はC++です。
swprintf()の定義を追っていけば、どのファイルに実装があるか分かりますが、どうも "%ProgramFiles(x86)%\Windows Kits\10\Source\10.0.*.0\ucrt\stdio\output.cpp" 内のcommon_vsprintf()の内部、processor_type::process()にバグがありそうです。processor_typeはテンプレートoutput_processorの特殊化ですが、その実装は "%ProgramFiles(x86)%\Windows Kits\10\Source\10.0.*.0\ucrt\inc\corecrt_internal_stdio_output.h" にあります。

余談ですが、C形式のAPIの内部実装にC++を使用することはよくあります。AndroidのBionic libcも、昔はすべてCとアセンブラで実装されていましたが、Android 4.xあたりで再設計されて部分的にC++で実装されるようになりました*3*4*5。なお、WindowsAndroidも、システム開発にRust言語の活用を始めているらしいので、将来的にCランタイムライブラリもRustで実装されることになるかもしれないですね。少なくともRustコードは教養として読めるようになっておいたほうがよさそうです。

クソ五輪は登場人物全員がクズです

もう気持ち悪すぎる。クソ五輪はゴミクズどころか吐き気を催す『邪悪』な餓鬼畜生どもが巣くう魔窟でした。類は友を呼ぶ。もともと大嘘つきのアベが自らの邪な欲望を満たすために、アンダーコントロールだなどと吹聴して無理やり招致した東京クソ五輪202Xは、最初から最後まで呪われる運命にあったわけです。AKIRAの予言は正しかった。

過去の暴行罪・障害罪を武勇伝のように自慢する極悪な低能マイナーミュージシャンくずれとその邪悪な血を引くサイコパス一族が地球にいたこと自体初めて知りましたが、このson of a bitchを採用した関係者はコイツの素性を知っていたんだろう? 海外のメディアから指摘されて初めて反応するとか、恥ずかしいと思わないのか? 過去に類をみないくらい最悪な形で全世界に醜聞をさらしたこのクズ野郎は、末代まで呪われることだろうし、またそうあるべきだ。ただの因果応報なので同情する余地は1ミリも残っていない。

本当に、本当にもう関係者全員首を吊って火あぶりにされて最大限苦しんでから死んでください。コイツらは社会に害悪しかもたらさない*1。全員死んでも誰も悲しみません。もはや五輪憲章がどうのこうのとかいうレベルじゃねーよ。暴行罪・傷害罪・侮辱罪で逮捕・投獄されるべきだった人間が、なんで大手を振って表を出歩けていたんだ?

そもそも「イジメ」とかいう生やさしい言葉で誤魔化すからダメなんだよ。「虐待」ですら甘い。れっきとした暴行罪・傷害罪・人権侵害でしょうが。そういう中途半端で生ぬるいことやってるからどこの学校も教育委員会も事なかれ主義で身内の犯罪をもみ消そうとするんだろうが。

ところで、普段はMIDI音楽しか流さない近所のスーパーで、なぜか昔のクソ五輪(2004年)のNHKテーマソングが流れていました。ヴォエエエエエエッ。吐き気がした。そういえばこいつら思想が右傾化してね? NHKは気色悪い右翼アーティストばっかり採用するよな。

*1:最低野郎のことをウジ虫とののしってはいけません。ウジ虫は分解者としての役割を持っており、自然界には必要不可欠の存在です。そんな彼らと比較するのはウジ虫に対して失礼です。

GitHub Copilotの違法性

GitHubに公開されたコードとコメントをベースに学習したAI(特化型の弱いAI)によって、関数名や設計コメントなどからプログラム内容を補完する「GitHub Copilot」という機能がプレビューリリースされ、試験運用が始まっています。同時に、この機能がもたらす問題についても懸念が持ち上がっています。

forest.watch.impress.co.jp

internet.watch.impress.co.jp

gigazine.net

今のところ自分はプログラミングだけで飯を食っているわけではなく、ソフトウェア設計や要件定義などの上流工程にも携わっているので、仮にAIベースプログラミングの進化がプログラマーの存在を脅かすことになったとしても特に困ることはありませんが、勝手に学習に使われるソースコード著作権問題が気にかかります。

自分はGitHubにいくつかコードをアップロードしていて、大半は緩めのMITライセンスで公開していますが、少なくとも「勝手に機械学習に使ってもいいよ」とは言っていません。そもそもGitHub利用規約にはソースコードフェアユースに関して書いてあるのか? 使われている言語やライブラリ、ライセンスやフォーク数などの統計データくらいであれば好きにしてくれてかまいませんが、ソースコード著作権は個々のライセンス規定に依拠するものであり、ソースコードアルゴリズムをパクってライセンス表記もなく無断で商用利用することは法律に抵触する可能性があります。GitHub Copilotがやろうとしているのは、ライセンスの違いを無視した何でもアリのちゃんぽん(無秩序・無法地帯の醸成)じゃないのか?

あなたが GitHub に投稿したコンテンツの所有者はあなたです。 ただし、お客様にはコンテンツの所有に伴う責任を負います。また、当社ではお客様にサービスを提供するために、一部の権利を当社に付与してくださるようお願いしています。

お客様は、自身が作成したコンテンツを所有することになりますが、お客様が投稿したコンテンツを当社が表示および共有できるように、特定の権利を当社に許可するものとします。 ただし、お客様が自身のコンテンツを管理し、それに対する責任を負うことには変わりありません。また、お客様が当社に与える権利は、当社がサービスを提供するために必要な範囲に限られます。 当社は必要に応じてコンテンツを削除したり「アカウント」を閉鎖する権利を有します。

「一部の権利」「特定の権利」「当社がサービスを提供するために必要な範囲」とやらは、どこまで適用されるものなのか?

無断利用の問題はAIによるパクリだけに限らず、人間によるパクリにも言えることなのですが、マシンパワーに任せた特化型AIによる自動学習は、人間の学習よりも遥かに膨大なデータを短時間で処理することができるため、より悪質な利用を爆発的に促進する可能性があります。

もし、AIによって自動生成されるコードが、学習に使われた既存コードの丸パクリになるようであれば完全にアウトだと思います。学習のさせ方にもよると思いますが、おそらく学習データが少ない場合、その可能性が高くなるのではないでしょうか。

この問題に関して、Linus TorvaldsやRichard Stallmanはどう反応するのか?

なお、日本語と英語の間の機械翻訳はいまだに実用レベルには達しておらず、幼稚そのものです。もし日本語のコメントからAIでプログラム内容を補完する場合、まず先にその課題をクリアする必要があるでしょう。
日本語で得られるIT関係の情報はほとんどが二次情報で、英語原文で得られる一次情報に比べると、現時点ですでに質も量も圧倒的な格差があります。
日本語を母語とし、普段から日本語で思考する日本人は、設計コメントも日本語で書くことが多いのですが、英語運用能力をおろそかにしていると、これから先は格差がどんどん開いていくことになると思います*1

ところで、GitHub上には良いコードだけでなくクソコードも星の数ほどあり玉石混交の状態なので、アンチパターンを間違って学習してしまう可能性もあると思うのですが、そのあたりどうなんでしょうか。しばらくは自己責任ということになるでしょうが、仮にAIを使ってプログラミングしたところで、結局のところ最終的に正しいコードかどうかを判断するのは人間です。AIによってサジェストされるようなコードすら書けないほどプログラミングスキルが欠如しているのに、本当にデバッグができるのか? 将来的に情弱が多数派を占めるようになる日本ではAIプログラミング自体ができず取り残されるか、AIプログラミングに頼るソフトウェアハウスが増えるものの、自動生成されたコードの良し悪しを精査できるスキルを持った人間がいないのでバグを作り込み炎上、という案件が増えそうですね。

*1:日本人が書く英文は分かりづらく、ソースコードのシンボル命名規則もムチャクチャであることが多いです。ヘタに英語でコメントを書くと誤解を招く可能性があります。例えば日本人が犯しやすいミスの傾向を把握しているような、Japanese-Englishに特化したAIエンジンでないと設計コメントの意図を理解できず、頓珍漢なコードが生成されてしまうでしょう。英語でコメントを書くつもりであれば、まずは英語で書かれたAPIリファレンスやドキュメントを読んで、ネイティブエンジニアがどういった単語や言い回しを使っているのか把握してからにするべきだと思います。とはいえ、自分もコメントは日本語で書くことが多いのですが……

給料泥棒の極悪人・林がまた横浜市長選に立候補しやがるようです

厚顔無恥とはまさにこのこと。再びこの極悪人を当選させるようであれば、横浜市は完全に終わっています。横浜の有権者はゴミクズしかいないってことになる。

自民の大ウソつき・アベの野郎が、オリンピック反対論者を反日だとかぬかしてやがりますがね。本当の反日というのは林みたいな利権ズブズブのクズ野郎のことを言うんです。歪んだ顔に邪悪で狡猾な本性がにじみだしている。

俺は反日だとか非国民だとかいう言葉は反吐が出るほど大っ嫌いですが、アベのほうがよっぽど反日・非国民です。本来、公文書偽造・贈賄罪で逮捕・投獄されるべき犯罪者が、なんでまだ大手を振ってシャバを歩いているのかまったく理解できない。日本は法治国家ではないようです。犯罪者が国会議員になれる恥ずかしい国・日本。

あとIR・カジノに賛成しているクソ野郎の有権者どもはすべからく反日ですから。こいつらは日本には要りません。とっとと出て行け。お前らの大好きな札束を抱いて東南アジアの紛争地帯にでも骨をうずめれば?

閃光のハサウェイ第1部を観てきました

映画は平日鑑賞に限りますね。前売り券は2019年の発表後すぐに買ったんですが、だいぶ延期されたのでようやく使うことができました。ていうか前売り券1,800円/当日券1,900円は高すぎだと思います。日本の映画を衰退させているのは映画産業の利権構造そのものだということがハッキリしました。だいたいもう今どきの邦画なんてクソしかないので、じわじわと自分たちの首を絞めて完全に死んでしまえばいいと思います。

で、本題のハサウェイですが、ドラマ部分はかなり面白かったですね。このあたりは富野由悠季の原作の力によるところが大きいと思います。原作小説は学生時代に読んだので、理想主義のハサウェイに感情移入していましたが、大人になってからは「やっぱテロリズムはダメだよな」と感じています。第1部で各所に伏線をちゃんと張ってくれている(と思う)ので、クソ劇場版ゼータみたいな邪悪な改変はせず、原作通りの結末にしてくれると信じています。

一方、映像や音楽・音声に関してはありきたりな感じで、今どきのアニメだったらまあこの程度か、というレベルのものです。特に目を見張るようなものは何もありません。過去の名作と比べるのは酷だと思いますが、80年代のOVAガンダム0080のほうが総合的な映像作品として遥かに魅力的でした。

原作小説の表紙と挿絵(美樹本晴彦)が好きだったので、劇場版アニメのキャラクターデザインは嫌いだったのですが、声も違うし実際ケネスとかもう全然別物になっていたので逆に別人として観ることができました。ホストみたいな声優ばっかりでしたが、全員ホストみたいなキャラクターデザインなのでもうどうでもいいです。
しかし、ギギ・アンダルシアの外見と声が一致していない(大人の女性の風貌なのにアニメ声すぎる)のは耐えられない違和感がありました。クェス・パラヤを想起させるということでアニメ声は外せなかったんでしょうが、だったらもう少しキャラクターデザインはどうにかならなかったのか。小説挿絵のギギは妖精的な美しさがあり、絶対に小説版のほうが可愛いと思います。これはもう原作小説読んでくださいとしか言いようがない*1。また、上目遣いに魚眼レンズ風の下品なカメラワークをもってくるのにも生理的な嫌悪感を覚えました。レーン・エイムもそうですが、眼球だけがギョロギョロしていて怖い。最近のアニメーターやキャラクターデザイナーは、確かに絵は上手いし、動きもなめらかなんですが、小綺麗なだけで、魅力的なキャラクターデザインをするのが猛烈にヘタクソですね。クソ劇場版ゼータとかガンダムUCとか、あの手の小綺麗で無駄にぬるぬる動く、小手先のテクニックに頼った無個性で気取った絵が俺は大嫌いなんです。

CGの使いすぎも気になりました。最近のガンダムって小道具・大道具問わずやたらCGを使いたがるんですよね。序盤の月面や、中盤でフィリピンの島々を上空から見下ろすシーンでは、キレイだなとポジティブな感触を受けたんですが、モビルスーツが完全にCGだったのがとても残念です。ああ、もう本当に手描きのロボアニメは死滅したんだなと。閃光のハサウェイモビルスーツは恐竜進化の果ての最終形であり、ゴテゴテした複雑なデザインになっているため、アレを手描きアニメで動かすのは難しいということはまあ分かるんですが、とにかく迫力がない。ゲームみたいな戦闘シーンでした。メッサーとグスタフカールの戦闘中、飛び散るビーム粒子で街が焼かれ破壊されていくシーンは良かったと思いますが、F91みたいに明確な死の描写とかしてないんですよね。序盤のシャトル襲撃の銃殺シーンでも血が飛び散るだけだし。つまらないなあ。一見残虐に見えるけど結局モブが死ぬ程度にしか感じられない。こういうところも(時間経過や画面スクロールで死体が突然消える)ゲームのようです。
とはいえ、エヴァ完結編のように人物の作画の下絵までCGでやっていることが丸わかりな部分はなかったように思います。そもそもエヴァの場合、映像がチープすぎて泣けてくるレベルなんですが。

クスィーガンダムはまあまあ原作デザイン(森木靖泰)に近いので良しとしますが、ペーネロペーの顔がカトキ臭くて猛烈にダサかった。だからさー、もうカトキなんかにやらせるなよなー。あいつのデザインはつまんないんだよー。ロボ成分が全然物足りない方はゼオライマーを観ましょう。

なんにせよ、第2部を楽しみに待っています。

*1:最近出た新装版は挿絵がないらしいです。若干高いわりに表紙も微妙なので、わざわざ買う価値はまったくありません。オリジナルの角川スニーカー文庫版を強く推奨します。新装版の企画を考えた人間は完全なる無能の極みですね。

CPUファンが回転と停止を繰り返して電源が入らない問題に遭遇……原因はメモリだった模様

先日マザーボードのCMOSバッテリーを交換して、ようやく安心して作業が再開できると思っていた矢先に再び悪夢のブルースクリーン。コードはDRIVER_IRQL_NOT_LESS_OR_EQUAL。
そして電源を再投入すると、CPUファンがちょっと回転しては停止、を繰り返す無限ループに陥って正常に電源が入らない(M/Bのロゴ画面すら表示されない)という問題が発生。
おいおいとうとうハードウェアが逝ったか……買い替えるしかないかも……と思っていましたが、他に何か解決策がないか探していたところ、下記の動画を見つけました。まさにこの症状です。

www.youtube.com

メモリ……だと……

ホンマかいな、半信半疑で筐体を開けてメモリを差し直してみることに。8GB×2を2/4 (A2/B2) スロットに差していたので、とりあえず1/3 (A1/B1) スロットに差してみます。
これでダメなら1枚だけ差してみるか、新しいメモリを買い直すか。

祈りを込めて電源投入。

……結果、あっさり起動。

あなたが神か

本当にありがとうございました。

ホコリが原因かも、と思っていましたが、少なくともCPUやメモリ周辺に関してはきれいそのもので、ホコリは一切載っていませんでした。
CMOSバッテリーを交換した際に、移動や振動でメモリの差し具合がちょっと変わって異常動作を引き起こしていたのかもしれません。あるいはスロットの故障という可能性も。
こういう症状は結構よくあるみたいですね。

fanblogs.jp

Windowsの今後

Windows 11ではハードウェア要件がかなり厳しくなるらしいし、買い替えもやむを得ないか、と半ばあきらめていましたが、試してよかった。
Windows 10のサポートが終了する2025年頃までには、今のハードウェアも完全にロートルになっているか、何らかのパーツがマジ故障する可能性が高いので、いずれは買い替えせざるを得ないですが、しばらくはまだ使えそうです。

それはそうと、公開が凍結された、くだんのクソみたいなシステムチェックツールの名前(PC正常性チェック: PC Health Check)がクレイジーですね。非常識極まりない。あんたらの掲げる要件を満たしていなければ不健全 or 異常だとでもいうのか。失礼な話だ。
そもそも不透明な足切り戦略はやめたほうがいいと思うけどな。PCに詳しくない一般ピープルからの総スカンをくらって墓穴を掘るぜ、MSさんよ。ただでさえChrome OSにシェアを奪われつつあるというのに。

昔は「Windows 10が最後のWindows」とか言っていたので、新しい後継OSはブランド名自体を変えてくるのかと思っていましたが、結果的に安直な11かよ。今のところプレビュー版の内部バージョンはWindows 10と同じ10.0らしいので、まあ百歩譲って「内部バージョンは10.0で最後」という意味ではあながち嘘でもないのかもしれませんが、最終的に11.0に変えてくる可能性もあります。
将来的に、WSLが本体になってWindows側がサブシステムになるという、笑えない状態になっているかもしれないですね。公式Wineかよ。

タスクバーも使いづらくなりそうだし、MSはWindows 8の失敗から何も学んでいない*1。そろそろWindowsには見切りをつけてLinux+Wineへの移行を本気で考えないといけないかもしれない。一番の問題はサードパーティー製アプリやゲームの認証の壁……

*1:Windowsアイデンティティでもあるスタートボタンをなくしたことで大ヒンシュクを買ったのがWin8で、その後Win8.1でボタンだけ復活させてお茶を濁し、Win10で結局タイルと統合して復活させましたが、また位置を変えるとか無能にもほどがあります。怒りを通り越して悲しさや哀れみすら感じます。本当に可哀相なWindows。上の連中も下の連中も、グチャグチャに引っ掻き回してダメにするバカしかいない。変更のための開発ではなく、開発(無駄な雇用確保)のための変更という本末転倒の暴挙。貧弱で安直な発想しか持たないアホどもがmacOSChrome OSのマネをしようとしているようにしか見えませんが、そもそもChrome OSのランチャーアイコンは左下に固定されているんです。だいたいシステムUIというのは、他にどんなアプリがいくら起動していようが、常に位置が固定されていて惰性で操作できることに意義があるんです。それが分からん無能は首を吊って死ね。