ウマ娘関連のネタが多いでしょうか
Xcode + (obj-)C 環境でけっこう出る。
おそらく関数の打ち間違い（strlen -> strln など）をそのままにしてビルドを強行してしまい、Xcode は気を利かせて？標準ライブラリのヘッダファイルの複製を作ろうとしているんだと思う。
もちろん、その必要はないし、Xcode SDK のファイルパーミッションはそれを許さない。
解決策は
・DerivedData を削除
・Xcode を強制終了
その後、再起動させるとアラートは出なくなります。
内輪で使われている言葉。
「オープンソース」だの「フリーソフト」だのといった言葉を使うとメンドくさそうな人が出てくるため、自由に使っていいソフト・アプリ・プログラムのことをこう呼んでいる。
「自由に」使えるならば、ソースが公開されていようがいまいがどちらでもいい。
（続く）
NativeMessaging では、現在（2024/5）、host 側アプリの入出力は stdio に限定されているので、本格的にアプリを組む場合には、stdio を操作する必要がある。
『標準入出力の操作方法(Obj-C)』という記事があるが、当然、これでは物足りない。
stdin されるのがキャラデータばかりではないからだ。バイナリも扱いたい。
んー。検討中。
ところで、このような場合、printf を安易に使ってはいけない。
printf は、fprintf の出力ストリーム先が stdout になっている関数のようで、書き込んだ内容は当然、stdout にダダ漏れなっていると思われます。
NativeMessaging の続き。
単純な host アプリ- chrome 拡張のプログラム系の連携は取れるようになってきたが、実用的には工夫が必要。
というのは、ブラウザから母体のアプリを使う必要があるのは、母体のハード資源を使いたいという時がほとんどで、大抵の場合、
ハード資源の応答速度は遅い
から。
店舗で PIN 打ち込んで決済する時、（おそらく操作端末に直結している）カードリーダー経由でも速度的には微妙な感じだが、あれをブラウザ経由でやろうとするわけだから、諸々の工夫が必要になってくるのはわかると思う。
工夫は、大雑把に２方向考えられる。
一つは、PC 側アプリで非同期処理などを実装する。（Mac の場合、ここなど参照）
もう一つは、chrome 拡張側の工夫。
Service Worker と host との通信には、二通りある。
（続く）
これはエラーではなくて警告でよく出ると思うのだが、この現象の解説がやはりというべきかここにあった。
char** ReadLineImpl::my_completion () {
char* matches[1];
matches[0] = "add";
return matches;
}要するに「単に配列などを定義しただけでは、一時的にメモリが確保されているだけなので、場合によっては正しいポインタを返さないかもしれないよ」という仕様由来の背景がある。
ああ、ややこしい。
解決策で最もわかりやすいのは変数を static で宣言することだろう。
なお、一般的な static の修飾子の説明はここあたり参照。