size() の型は

コメントを残す

Xに、問題として上がっていたこんなコード（実際の問題とは違うが、要は i < v.size() – 1 の評価のところで。

#include <iostream>
#include <vector>

int main(void)
{
    std::vector<int> v;
    int count = 0;
    for (int i = 0; i < v.size() - 1; i++) {
        count++;
        std::cout << count << "\t" << i << "\t" << (v.size() - 1) << std::endl;
        if (count > 5) break;
    }
    return 0;
}

この結果は

1 0 18446744073709551615
2 1 18446744073709551615
3 2 18446744073709551615
4 3 18446744073709551615
5 4 18446744073709551615
6 5 18446744073709551615

となるわけで、iがint、v.size() – 1 はunsigned long なのだから、0から-1を引いても大きな値になっちゃうわけで、評価式は偽になりえないっちうわけで。

問題としては、この結果がどうなるか（無限ループ、SEGV、何も起きない、みたいな選択）ってことだけれど、まぁストッパがなければ無限ループになるわけで。

結論としては、イテレータ回せ、ってことで。

Windows10のSecureBootUpdateでフリーズ

コメントを残す

DELL – Inspiron のi5あたりの古いデスクトップで、今朝から画面が固まるヘルプ。

Windows起動後、タスクバーが出てデスクトップが表示され操作可能な状態になってから５分後くらいに突然画面がフリーズ。マウス操作も効かない状態となる。

SafeModeで起動すると問題は出ないので、一度
sfc /scannow
とかやってみるが特に異常なし。

C:\Winidows\System32 を覗いてみると、
SecureBootUpdate
というフォルダが同日午前０時過ぎに作成・更新されているのを発見。

ということで、Windowsを再起動で通常起動させ、起動後すかさず
タスクスケジューラを開き、Microsoft/Windows/PI/SecureBootUpdate を「無効」にする。

うちのPCは古くってそもそもSecureBootに対応していないので問題なく動作中。
DELLの方は何やら相性問題なのか、とりあえず動かないとまずいのでこれで一旦良しとする。
証明書関連の事象らしく2026年6月にはウンタラという情報もあり、それまでにはBIOSとか何某かのUpdateを探そうかと思う。（Win10のESUの関連もありPCを新しくするのが一番なのだが）

Windowsってのはいつも突然に

「伊達にして帰せ」考

コメントを残す

Xでの投稿で、んん？？？？となってちょっと調べてみた。

「伊達にして返すべし」＝「ヤベー」の意味が最初はさっぱりわからず。
これまでの知識の中では「伊達にして」＝「派手に飾って」と変換されるので、何がヤベーのか。
本来、”捕らえた熊に対して「伊達して帰せ」”は、山内一豊の山内家の逸話として司馬遼太郎が残した言葉であり、山内家の慈悲や寛容さを称える表現で、ここで使われる「伊達」は「派手に飾ること」を意味する。

もちろん熊に豪華な服を着せるわけではなく、鳥獣に対しての「伊達にする」は、首輪や識別標識を付けるなどの意味だろう。それにより他所で人に対峙した際にも安全に扱われる可能性が高くなる。
ということで、前述のXのポスト内での「伊達にして帰すべし」ってのもそういう意味だと受け取ったのに何がヤベーのだろうかと。

そこでGrokに「何が”ヤベー”のか」聞いてみると、
漫画”シグルイ”の影響で、現代（というかSNS上）では「伊達にして帰す」は、「ボコボコにして帰す」「存分に痛めつけて帰す」意味で使われているようだ。
伊達＝伊達政宗＝独眼竜と変換されて場合によっては「身体を欠損させて帰す」という残酷な意味として使われる。
大奥に忍び込んだ男が女達に、伊達にして＝男前にして＝耳鼻を削いで、帰されるというような話も創作されている。

元々「慈悲深い」寛容さのあらわれとして使われる言葉がなんとまぁ恐ろしげな言葉になってしまっている。たぶんシグルイ以降（2000年以降を主として生きている方面）では、”ただではおかない”という脅し文句に成り果てた感があるのが調べてみて初めてわかった。

元ポストの意味も、「伊達にして帰すべし」＝「ヤベー」の聞き手による意味の差が面白がるところだったってのも、このあたりでようやくわかったりする。

言葉というものは変わっていくものだし、そういうものだと思うしかないんだが、
プログラミング言語でも色々あるしなーとか。

LEDライト

コメントを残す

USB-A給電のLEDライト。
フレキシブルなアームで、タッチボタンによる3段階調光。白色光のみ。
期間限定ポイントの消化のためにポチり。

思ったよりも（車のLEDイルミとかとは違って）大きくてちゃんとしてる。
光量も問題なく、LED部のシェードやタッチボタン、USBコネクタ、シリコンアームなど、妙な部分が無くしっかりした作り。
ちょっとまとも過ぎてびっくりするくらい。
耐久性はまだわからないけれど、600円台だしポイントだしまぁいいかな感じ。

デスクライトとして蛍光灯と比べるとさすがに光量は少ないが、PCの手元を照らす／ベッドサイドでの読書灯とすれば十分の光量である。作りも簡単だから改造好きな人なら楽しめるかもしれない。

Excel VBA考

コメントを残す

LLM一辺倒なこの時代に現場の業務はというと、
EXCEL VBA
なのである。

開発ベンダや運営からすると、既に料金支払い済みのMS-OFFICEを利用するだけの作業として捉えることができ、費用を十分に削減できてしまう。開発者にもたかがExcel VBAに工数を計上するほど落ちぶれてはいないと思わせてしまう。

ただ、世の中に”セキュリティ”という言葉が出始めた頃、その脆弱すぎる形態により何よりも先に禁止の扱いを受けたのがExcelマクロである。
Openイベントで自動実行させられ、Windows-APIが自由に呼び出せてしまい、稚拙な暗号処理によりいくらでも改変できてしまうこの”強烈なおまけ言語”は実にやっかいで、アプリケーション作成側から見ると「やりたいことが素直にできない」実に不自由を強いられる言語であり扱いずらい。
さらに、一見簡易スクリプトとも言えるので、事前の設計が十分でないことも許容され、修正や要望など後出し追加作業についてもなし崩しで無報酬となる例が多い。
さらにさらに、「それなりに使える」事務職のせいで、”いぢくられた”マクロが戻されてくる場合も多い。

ゼロ・トラストが叫ばれる中、このExcelマクロは使用すべきではないしMicrosoftがデフォルトで実行しない設定にしているのは正しいと思う。かつ開発者には一つも利点が無い。

開発者ならExcel VBAをより安全に利用するには、を考えるべきという意見もあるだろうけれど、使ったところで利点が無いし、本来ならちゃんとした他の言語を使わせてもらいたい。
何よりWindows上でMS-Officeが必須という、お金払わねば環境を作れないものはその後の運用にも必ず悪い影響を残す。
”WSLは禁止だけどExcel VBAはOK”なのはなぜなのかと小一時間問い詰めたい。

とまぁMS365に月々持っていかれるのが不満たらたらなフリープログラマなのでした。

Wireless Keyboard

コメントを残す

Temuで500円で買ってみたゲームコントローラ風Wireless Keyboard。中華製2A6BG-I8

単４電池２本でドングル差し込んで動作する。

Ubuntuでもサックリ問題なく、キーボード入力、タッチパッドでの操作、マウスクリックなど全てきちんと動作する。
このモデルはmicroUSBの口は付いてはいるが充電には対応していないっぽく単４電池２本での動作のみっぽい。
Config-A版のだとリチウムイオンバッテリでmicroUSBからの充電ができるらしい。
また、マニュアルにはBluetooth切替の記載もあるが、この版では機能が無いっぽい。（Fn+F3でも反応なし）

左上の丸ボタン（ボリウムや再生／次／前）は当然ながらUbuntuでは機能しない。またタッチパッド周りのショートカットボタン（メールやら音声OFFやらIEやら検索やらの小さいボタン）もUbuntuでは機能しない。
当然だがWindowsではそれぞれきちんと機能する。

とりあえずの用途は自宅内でのサーバ類（ラズパイとか）の操作でいちいちキーボード持ち歩く必要がなくなるのと、出先のサーバ類の操作がちょっと楽になる。となると次は小さいモニタが欲しくなるよなー。ドングルタイプでスマホに映すやつとか探してみよう。

Windows10 ESU登録

コメントを残す

個人で1年間のセキュリティ更新を受けるためESU（Extended Security Updates）に登録する。

有料で3,500円かかる、という話だったが、登録画面を開いてみると、
「既にバックアップなんちゃらがどうにかされているので～」とかで、無料で登録できるようだ。

ってことでサクっと登録。

新しいマシン欲しいんだが、Win10機で使っているのはVirtualBoxでLinuxサーバいくつも起動させて、Linuxのノートから接続するような作業ばっかりなので、特に何も不都合なく。

外部機器もプリンタくらいしかないので、昨今はLinux用ドライバもしっかりしており何ら問題ない。唯一、Adobe ReaderによるPDFへの電子印鑑（なんちゃって）の利用くらい。簡単な編集（Text追加したりハイライトしたり）はLinuxのPDFビューアでもできるんだけれど、Wineしっかり設定するのもめんどいし・・・とそれだけ。

と、1年間の猶予ができたのであります。

2038年問題

コメントを残す

SoftwareDesign2025年8月号でも取り上げられていたが、2025年になってもまだ2038年問題なのである。
実務上最大の問題はMySQLでのtimestamp型が32bitであることか。だがこれは多くの場合DateTime型へ移行することで問題のないものとなる。
C上での問題も素直にtime_t型を使用していれば通常の問題はないし、strftime()を使っての書式化であれば全く問題など出ない。
世の中の技術者を大いに困らせているのは、time_tをlongでキャストしているバカタレの尻拭いであり、こいつらは意気揚々と「シリアル値の演算で通算秒の差をとれる」とか言いながらせっかくのtime_tをlongでキャストしやがるのです。
そもそもお前はlongがどういうものなのかわかっているのかと小一時間問い詰めたいと20年以上前に語った記憶があるのでまぁそれは置いておいて。

型が時代とともに変化し、同一ソースでは想定外の挙動を起こすことはlongに限らず良くあることではあり、じゃぁどうするのが一番良いのかと人間はいつも考え続けるわけで。
特にC/C++に於いては速度やサイズが重要である場面が多く、型のbit数を把握した上でのコーディングも少なくない。（だからbit演算とかがゴリゴリ出てくる）
とはいえこれらもsizeofやlimits.hやstdint.hあたりをきちんと使えばマジックナンバーを埋め込まずともコーディングは可能なのだから、そうすれば良いだけの話。

で何が言いたかったのかというと、
日時演算は専用関数作って使え
ってことで。問題あってもそこだけ直せば良いのだから。
long32にしたところで、(cur_dt + target_dt) / 2 とかやった時点で2038年を待たずにアウツなんだから、後続のために最低限日時演算処理は別ファイル別関数にしとけ。