あとでよむ https://ascii.jp/elem/000/004/183/4183947/

あー…（USB3.0はそのままスルーして、USB2.0部分だけ3ポートのハブを介すってことか…）

@lo48576 ですです、なので差し込みのタイミングによってはUSB3.0ホスト/USB3.0デバイスの組み合わせでもUSB1/2な速度になることがあるという… https://qa.elecom.co.jp/faq_detail.html?category=&id=8372

こんな時間からNetBSD-current(10.0-RC4)のビルドをおっぱじめてしまったので寝るまでに終わるなんていうのは絶望的だわな…

OHCIとUHCIがUSB1.1(Low/Full-speed)、EHCIがUSB2.0(High-speed)、xHCIがUSB3.x(Super-speed)だけどUSB1.1(Low/Full-speed)/2.0(High-speed)にも対応できるって話だったよーな。

H616対応は終わったようなのでもう/usr/srcのｵﾚｵﾚ差分は全て破棄して良いでしょう（というかしました）。

あとは/usr/portsのｵﾚｵﾚ差分をどう始末したもんか…

捨てました。流石にもうOHCI/EHCI/UHCI大量にホストコントローラぶら下げる時代でもないですし。

diff -u -p -r1.36 usbdevs.c
--- usr.sbin/usbdevs/usbdevs.c 28 Dec 2022 21:30:19 -0000 1.36
+++ usr.sbin/usbdevs/usbdevs.c 18 Feb 2024 12:27:50 -0000
@@ -271,7 +271,7 @@ main(int argc, char **argv)
int i;
int ncont = 0;

- for (i = 0; i < 10; i++) {
+ for (i = 0; i < 24; i++) {
char path[PATH_MAX];

snprintf(path, sizeof(path), "%s%d", USBDEV, i);

…要るか？捨てるか…？

VERASE2だと…stty erase"2"だと…（困惑中） https://github.com/DragonFlyBSD/DragonFlyBSD/blob/master/sys/sys/_termios.h#L56

あーalsa v1.2.11出ちゃいましたかー（ということをvoid linuxのアップデートで知る）。直さないと…

nginxのフォークってengine-xにならないのかなあ。nginxよりも読みやすい！なんて。

情報量多いよ…ｗ

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

野生化したサーバとか野良ドメインとか…

#そもそもサーバの野生化とは

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

（Oracle(Sun)のコンパイラ、とかもあったんでしたっけ…）

JavaScript界隈でも三項演算子禁止令とかあるのか。
【2つの理由】三項演算子は仕事で使うべきではない (2022/3/28)
https://skyblue-dev.com/ternary-operator/

「１．三項演算子を一切禁止する。（推奨）
２．入れ子がない場合に限り、三項演算子を許可する。
３．条件部が単一条件の場合に限り、三項演算子を許可する。
４．条件部が単一の真偽値変数に限り、三項演算子を許可する。」

自分は2.。流石に三項演算子の入れ子は意味分からなくなるのでこれは避けてる。

まあ確かにコーディング規約があるならそれに従う、のは当然だよねえ。

あー、sj3のUTF-8化はどうしたもんかなー。なんとなくこんな感じの物を追加すれば良いのかなーという感じはしているんだけど、bskeyの追加みたいに害無さそうなコードを入れているはずなのに動作が妙になるというのを見てしまうとビビってしまって。

リソースの確保と解放は必ずペアにする（エラー発生時に処理を抜ける際もちゃんと解放する）、switch～caseはdefaultを忘れない、というのは気を付けるようにしてる…つもり。まあ気を付けても忘れるのがヒトなので、モダンな言語はその辺を楽させてくれなくても警告は欲しい。

自分ではコード書くときに今のところRustは選ばないけど、既に書かれている物を触るとか便利そうなライブラリがあればそれで書けるようにしておくとか…準備はしたいなあ。

（不慣れだけどC++を使うのはSTL便利だし…という理由による）

switch～case、今はdefaultとそれ以外の場合分け（だったらif文で済むよね？）というケースでも、将来ここになんか追加機能を突っ込むかもしれないなーという時は割と使うかも。

自分もCS出ではないんですが…なんでこんな人間が組み込みやってたんだろう（遠い目

あー言われてみればOpenCLもCっぽいけどCから微妙に違う何かなところがあるから、再利用したいというのはあるかも。

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

gcc以外で使ったコンパイラっていうと、GreenHillsですかねえ。流石にCPUについては秘密とさせてくださいなんですけど（もう10年以上経過しているので触れちゃっても良いのかもしれませんが、守秘義務ってことで）。

え、C言語って普通にswitch~casseありますよね。K&R本初版にも書いてある（って今ページをめくったｗ）。

組み込みでもgcc使うケースって多い気がしますが、どうなんでしょう（ルネサスとかMicrochipのマイコン辺りだと非gccというケースはありそうですが）？

ああでもアセンブラ狩りって聞いたことないですね。流石にお仕事取れるレベルではないですけど…趣味でちょいとマイコンをいじる程度ならまだ何とか付いていけるかもしれない。やっぱあの手のうるさいのを黙らせるならアセンブラ（待て

でも言語仕様がこれだけ進化しても、そのうち「老害Cerは死ね」とか言われちゃうのかな。日経何とかで「コボラーは死ね」とか散々偉そうに言っている誰かさんみたいに（ああいう手合いってコボラーが滅んだら今度はCとか古めの言語使いの首を狩りに来るんでしょう？魔女狩りとやってること変わらないじゃん）。

【C言語】C23規格のプログラミング【GCC 13.1/Clang 16.0を利用】【使い方】 (2023.6.13) https://hiroyukichishiro.com/c23-standard-in-c-language/

clang-16は未対応だけどgcc-13.1だとauto（型推論）が使えるとか、C言語どこ行っちゃうのって感じですね（C++だとC++11からautoが使えていたのでそれを取り込んだのかなー）。

C11の仕様－脆弱性対応に関連する機能強化点 (2014/3/14) https://www.buildinsider.net/language/clang/02

printf_s()、OpenBSDでは実装してないみたいだけどそもそもOpenBSDのprintf()は%nを受け付けない（警告文の表示に加えてcore吐いて落ちる）。manにもこうあるし。

The %n conversion specifier has serious security implications, so it was changed to no longer store the number of bytes written so far into the variable indicated by the pointer argument. Instead a syslog(3) message will be generated, after which the program is aborted with SIGABRT.

まあ、時代が戻ることは無いはずなので…clangもgccの拡張文法がそれなりに通るし、可読性が悪くならなければちっとは使ってみても良いのかもしれない（C11, C17とかで規格化されているなら遠慮する必要も無いし）。

C11以降のモダンな文法、そういえばちゃんと知らないから…何かの折に知っておきたいな。

発端はswitch～caseのcase 0x00 ... 0x7f:というのを使ったこと。これを使わないとなると、defaultで受けてif文で範囲見て処理を分ける…けど、defaultの先にも処理の記述があるとめんどいよねという時にこの拡張文法は結構ありがたいなって。

gccの拡張文法、1995年時点だとあまり使うなっていう話があったけど（確かに自分がプログラマーやってた時代は割と禁忌な扱いだった）、イマドキのCとしてはどこまで許容されるんだろう。

gcc(Gnu C Compiler)の拡張文法(1995/10/21) http://cms.phys.s.u-tokyo.ac.jp/~naoki/CIPINTRO/gccextend.html

流石に三項演算子の二項目目の省略は…
n = (n < max) ? n : max;
n = (n < max) ? : max;
こういうコードなら別に省略しなくても良いのでは？という気がしなくもなく。省略したい気持ちも分からなくはないけど。

うーん、H3の打ち上げ、H2Bの最初の頃みたいな「新しい時代へ(F1)」「希望に満ちた明日へ(F2)」「全ての人類のために(F3)」（F4以降は無し）といった文言入ってないんですね…ちょっと復活するかなーって期待しちゃったんですけど。

（結構好きだったんですよ、アレ）

※中国語に関するスキル、自分は一切持ってません

なんか中国語版が出てきそう（見てみたい）

あ、U+FFFDってUnicodeにおいてはそれ使うって話だけど…EUC-JPでそれに対応する文字って無いんじゃ。

UTF-16LE/BEって要するにバイトストリームで流した場合に下位8bitか上位8bitのどっちを先に流すんよという話だと思ってた。

解釈不能な 「�」の文字ってU+FFFDなんですね…

とはいえ、UTF-8 decoder capability and stress testであっても、下位サロゲート→上位サロゲートの順に記述した場合のテストは無い。

というか、UTF-8においてはサロゲートペアの概念は無い（使わない）のでサロゲートペアを示すエンコードが行われたとしてもマトモに表示できなくて当然…で良いんだよね？

これだ！
UTF-8 decoder capability and stress test https://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-test.txt

これではなくて https://www.w3.org/2001/06/utf-8-test/UTF-8-demo.html
うー、とにかくおかしなUTF-8というのを集めたテスト用のファイルをどっかで見てるんだよ…

（検索中）

では、サロゲートペアは何文字の「不正な文字がおるで」を吐くことになるんだろう…まとめて1文字か、あるいは各サロゲートに対し1文字なのか。（嫌だこんなこと考えたくない…！）

あー、サロゲートペアあるか…

どうせ出力はUTF-8、内部ではEUC-JPに変換！なのでサロゲートペアは「知らんがな」という扱いにするしかないかも。

正しくないUCSをエンコードしたUTF-8の扱い、そのバイトストリームをまんま放り出すか、1文字分の「なんか不正な文字がおるで」的な文字を1文字返すかは悩みどころ。あんまり賢くは無いけど、個人的には後者にしちゃいたい。

避けたいんだけど、文字コードに応じn byte分バッファリングしてwchar16_tの形に変換～なんてコードを拡張するとなると結局自前でUTF-8デコードを避けられないという気がする。

※一部修正しました

躊躇わずにまずはコードいじってみて、ダメなら投げるしかないか…

構造上自前でUTF-8をいじらないといけないように見える（iconvを通す余地がなくはないけど）、という案件な気もするんだよなあ。

「自前でUTF-8を処理しない」 https://gihyo.jp/admin/serial/01/charcode/0004

やっぱそうすべきなんですかねえ…

EUC-JPからUTF-8へ変換する場合、補助漢字を使っていたとしてもせいぜいU+FFFFの範囲には収まり…ませんね。 https://ja.wikipedia.org/wiki/UTF-8

spamな通知、ただのブロックではなく通報付きブロックの方が良いのかなあ。とはいえ通報された相手の仕事が増えるだけなんだけど…

うーん、設定である程度回避できるとはいえユーザ体験（って言葉は好きじゃないけど）を悪化させる問題は解決したいしとはいえ優先順位は低くもないけど高くもないしほんとにどーすんのこれ。

むしろとりあえずUTF-8環境でおかしくならないような対応を先にやらないと困るっていうのが現実なんだけど。

ちょいうろ覚えなんだけど…（いちいちgitで件のcommitまでもどるのめんどいし）、bskey設定を有効にすると「あいうえお」は一連の文字列になるのに対して子音が混じるか何かすると区切られてしまうという症状が起こるような。なのでrevertしてる。

delkeyって-1のままなはずだし、0x7fは頑張っても（charとして解釈して符号拡張しても）0x7fのままなので影響は無いと思ってるんだけどなんかあるのかなあ。なんかあるからおかしな動きをするはずなんだけど。

ラーメンショップやくるまやラーメンは全国区みたいだし…対抗できるのは増田屋くらいなんだろうか（それラーメンじゃなく蕎麦ですけど…）

ラジオCMでおおぎやラーメンなるお店の存在を知ったけど、これも神奈川近辺には存在しない… https://www.oogiya.com/tenpo/index.html

神奈川の地でもスガキヤの名前は聞いたことあったけど…とおもっていたのだが、関東から撤退していたのか。 https://ja.wikipedia.org/wiki/%E3%82%B9%E3%82%AC%E3%82%AD%E3%82%B3%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E3%82%BA#%E6%92%A4%E9%80%80%E5%9C%B0%E5%8C%BA

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