かつては何かの意味があったことは確かであり、その意味を汲み取りたいところではあるが、今日においてはその意味は希薄であり、意図を汲み取ったところで無用である可能性が高いと判断されるのであれば、それは切って捨てるのもやむなしということになるのだろう。
まあ、一旦切って問題があることが分かれば、また戻せば良いだけの話…かな?カジュアルにやっても多分咎められないと思いたい。
OpenBSD, Ham(JG1UAA), Ingress(Lv14, RES), Japanese(Sagamihara-city, Kanagawa)
Another side: https://social.tchncs.de/@uaa
npub1rarr265r9f9j6ewp960hcm7cvz9zskc7l2ykwul57e7xa60r8css7uf890
Messages from this Mastodon account can read via mostr.pub with npub1j3un8843rpuk4rvwnd7plaknf2lce58yl6qmpkqrwt3tr5k60vfqxmlq0w
かつては何かの意味があったことは確かであり、その意味を汲み取りたいところではあるが、今日においてはその意味は希薄であり、意図を汲み取ったところで無用である可能性が高いと判断されるのであれば、それは切って捨てるのもやむなしということになるのだろう。
まあ、一旦切って問題があることが分かれば、また戻せば良いだけの話…かな?カジュアルにやっても多分咎められないと思いたい。
canuumのソース見てみたけど、自分の理解だとsj3みたいに文字コードの種別に応じ文字境界単位での出力を~といった感じの物は、見当たらない。おそらくprintf.cのflushw_buf()の処理になるんだろうけど、バッファの内容をputchar()でべーっと吐くだけ。
canuumもNEWS-OS対応していて、このコードでも動くというのなら…出力時における文字境界単位でなんかやる意味って本当に無いってことにならんか?(sj3の、オリジナル…コメントがちゃんと存在する状態のコードを見ない限りその意図は分からないってことでもある)。
putchar()で標準出力に吐くにしても、吐いた先で一旦バッファリングしてからwrite()なりなんなりするはずだと思うんだけど…
canuumとかのソースを見る?
あんまり難しく考えなくて良いのかなあ?「2byteで構成する!」なら2byte、「5byteで構成する!」なら5byteとりあえず拾って、その拾ったものが正しいかどうかを検証してグリフにするかエラーを吐くかを決める。変な気遣いはしない方向で。
https://gist.github.com/RobertAudi/9f1ce1d5ecc9c12ae5c4c6c086369c5c
3.3 Sequences with last continuation byte missing
All bytes of an incomplete sequence should be signalled as a single malformed sequence, i.e., you should see only a single replacement character in each of the next 10 tests. (Characters as in section 2)
って書いてあるけど、Firefox上での表示は"only a single placement character"にならないケースがあるな。
ISO 10646のAnnex Rってのはこれかな? https://www.cl.cam.ac.uk/~mgk25/ucs/ISO-10646-UTF-8.html
UCS Transformation Format 8 (UTF-8)
sj3のwrite_stdout()、3byte EUCの場合(SS3, 0x8f)…2byte目ないし3byte目がEUCの範囲を外れていてもとりあえずホールドしてる感じですね。これはSJ_read()に関しても同様。
SS3, CR, 'a'みたいなシーケンスになった場合、おそらくSS3を棄却、CRと'a'を表示というのが理想なんだろうけど、って不正なEUCを食らった場合の扱いというのもどうなってるんだろう…いやそもそも不正なEUCとは…
セキュリティを考えると、不正なエンコーディングに対しては頑なに受け付けないという作りにするしかない(MSB側の2bit分を無視するという実装は許されない)気がするけど。
UTF-8、複数バイトからなる場合の2nd octet以降のMSB側"10"が正しくなかった場合ってどう扱うんだろう。
とりあえず1st octetの規定に従ったoctet数だけは読みだして、まるっと棄却するとかそんな感じで良いのかな。
不正なエンコーディングに対する処置をどうするかっていうのがRFC 3629( https://tex2e.github.io/rfc-translater/html/rfc3629.html )を見てもよく分からなくって。
nsdemu -l <serial device> -k <secret key>
というのは確かにスジが悪い(ps axで他のユーザにsecret keyがモロバレ)のは分かってるんだけど…テスト用途なのでとりあえず許せとドキュメントに書いていてもクレーム付けてくるんだろうなと震えてる。
PU2CLR SI4735 Library for ArduinoのREADME.md、よくこんだけの量を書いたもんだと戦慄している… https://github.com/pu2clr/SI4735/blob/master/README.md
This account is not set to public on notestock.
age_map["alice"]=30;が、3行に分かれる(引数を&つけて取るので直接値を入れられない箇所があるが、2行まで減らせませんかこれ)というのはなかなか大変なものがあるけど…連想配列を使えるのは楽かもしれん。
とはいえ、素直に「C++覚えてそっちでやったら?」と言われてしまうのもなんか分からなくはないような…
This account is not set to public on notestock.
しっかし、memset()が最適化で消えるのは恐怖しかないんだけど…そこはちゃんと仕事させてくださいよ…
「イマドキのC」(イマドキのC++とかじゃなく)というのも知っておかないといけないですね…Modern C(Jens Gustedt, 2019, https://www.amazon.co.jp/dp/1617295817)とか21st century C(Ben Klemens, 2014, https://www.amazon.co.jp/dp/1491903899)辺りは読みたい読みたいと思っていますがなかなか実現には至っておりません…
この手のやつだとmemset_explicit(最適化で消えないmemset。OpenBSDでいうexplicit_bzeroみたいなやつ。ゼロクリア以外もできるけど)がC23に入りますね。
nostr知らなかったらsecp256k1みたいな暗号系のライブラリ使うこともなかったし、いい勉強になった。
malloc()で確保した領域をfree()で開放はするけど、その際にクリアしてくれるfreezero()はOpenBSD-6.2から入ってる。 https://www.openbsd.org/62.html
しっかし、メモリ上に機密性の高い情報をあんまし置いときたくない→作業が終わったら消そうというのを突き詰めていくと、(C言語でいう)関数実行時のスタックフレームを関数終了時にクリアして抜けるとかそういう世界になりそう(でもどの程度スタック使ったかとか、安全に消せるのかといった問題があるので無茶なアイデアではある…せいぜい、alloc()などで確保した領域を0-fillするのが限度だよなあ)
This account is not set to public on notestock.