若くないけど斧を今知りました…本当だってば！

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

もうだいじょうぶです（ぐへへ

やっとCanna/FreeWnnを斧から落としてこれた…

@hadsn （副音声）「まさかデータシートも見ずに質問するなんてことはしてませんよね…？」

@hadsn 「データシートを見たらある程度推測できませんかねー？」的なコメント投げときました。

ほんっと、「さあこれから」ってタイミングで必ず刺されるのは何故なんだろう。

斧、えっちな広告のおかげでなかなかダウンロードできない（背後で妻子がうろうろしてる…これからダウンロードしようとした瞬間に！！💢💢💢）

【uaaの年末年始】
12/26 飲酒
12/27 飲酒
12/28 飲酒
12/29 飲酒
12/30 飲酒
12/31 飲酒
1/1 飲酒
1/2 飲酒
1/3 飲酒

#私の年末年始予定表 #shindanmaker
https://shindanmaker.com/954489

せいぜい大晦日～三が日くらいに留めたいなあ、飲酒。肝臓壊す訳にもいかないし、酒代も安くない。

axfcって斧って言われてるんだ（また一つｶｼｺｸﾅｯﾀ

企業に対して開示せよ、っていうなら理解するんだけど…コミュニティベースの（回路図も出ている）ハードウェアで開示しろって大上段から言われましても…

データシートを見た上で質問しているかどうかで判断することにします。

「下記項目について開示下さい」って、どういう日本語なんだろう。
「下記について教えてください」なら分かるんだけど…

とはいえ、(curdic->getdic)((struct dictfile *)(struct dictのポインタ), foobar)というのは明らかに「正しいコード」ではない…

かといってStruct.hのstruct globalにあるDICT *Jcurdictをstruct dictfile *Jcurdictにするとか、struct dictfile *JcurdictFとかリネームした上でsj_rename.h側で頑張るっていうのも…頑張れなかったんだよね（自分のスキルでは、というのもある）。

うーん、DictFileとDICTの共通化とかそういうのは難しそうな感じ。消極的だけど、キャストで逃げるしか無いかも。

詰んだ…

/home/uaa/z/sj3/kanakan/adddic.c:151:45: error: no member named 'segunit' in
'struct dictfile'
if ((*curdict->putdic)(curdict, curdict->segunit))

あー、第一引数はそれで文句を言わなくなったけど第二引数で怒られるのか。

GlobalのDICT *Jcurdictを、DictFile *Jcurdictに変えたら何が起こるか実験してみるか…

Global *work_baseの中にDICT *Jcurdictが居て、work_base->Jcurdictをcurdictで呼べるようにdefineしてる。

DictFileはDICTのスーパーセットになるってことは、サブセットのポインタの裏でスーパーセット扱うのってぶっちゃけどーよって話になる？

sj3libの、string.c関連のwarning、__sony_news絡みのコードを活かすか殺すかで作業方針が変わると思う。個人的には殺して良い気がするけ（今更NEWS-OSで動かさないといけないという理由は無いはず）。

あのコードで出ていたTLIってのはそれなのか

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

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

@omasanori もしかするとマージ済かもしれませんが、-Wimplicit-intのwarning潰し(2)と https://git.sr.ht/~jg1uaa/sj3/commit/c844bc906f9076ff7ade6c4f50081d57d4ec1feb -Wpointer-typeのお手軽に潰せたwarning https://git.sr.ht/~jg1uaa/sj3/commit/d3c7742bb4093bf90819c49c9bfc6033cd4238a2 置いときます。

うえぇ、終わらないよう…

【休業のお知らせ】
お客様へ

夏休みの宿題が終わらない為、本日休業します。

洋食屋uaa 店主

#休業のお知らせメーカー #shindanmaker
https://shindanmaker.com/1186544

さて、アドベントカレンダーの仕込みはこれでほぼ終わり。カレンダーの前後の記事のリンクを調整すれば出せるはず。

@nikolat 了解っす

@nikolat 現時点ではまだ未公開なので403になります

@nikolat http://uaa.org.uk/gomitext/2023/202312.html#02-Dec-2023
予定地です（ああああ自分のプロジェクトを進めるの忘れてた…）

@omasanori アイデアとしては４つ。
- 全てスーパーセット(struct DictFile)を使うようにする
- struct dictfile, struct dictからなる共用体を作りこれを使うようにする
- voidで受けておいて内部で然るべき型に解釈する
- struct dictfileへのキャストで対応する

手を掛けつつも掛けすぎない落とし所がなかなか難しいです。

@omasanori -Wincompatible-pointer-types対策のうち簡単に逃げられる箇所だけ直してみましたが…curdict周りの問題は一旦置いといたままにしています。
struct dict(DICT)の中にstruct dictfile(DictFile)を要求する関数が定義されており、DictFileの中にDICTが含まれているのをどう解決するかが厄介そうだという理由です。
変更箇所が多いのでsj_rename.h辺りでキャストしちゃうのも手なのかもしれませんが、要となる部分のコードですしその場しのぎの修正をするよりかは手間をかけてでも正しい形に持っていく方が今後にとってプラスになるのかなと考えています。

Struct.hにあるstruct dictfile(DictFile)がsj_struct.hにあるstruct dict(DICT)を内包していて、内部では都合よく使い分けてるけどコード的にはちゃんと記述せーよという場合をどう直したもんかね。

現状では受け手がスーパーセット(DictFile)を要求しているのに対し、ミニマルセット(DICT)を渡そうとしてwarningになってる。