This account is not set to public on notestock.
Posting らりお・ザ・何らかの🈗然㊌ソムリエ(@lo48576@mastodon.cardina1.red)
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
一括払い版「CLIP STUDIO PAINT」の無償アップデートが年内終了 23年に“バージョン2.0”をリリース - ITmedia NEWS
https://www.itmedia.co.jp/news/articles/2208/22/news143.html
This account is not set to public on notestock.
こういうの、仕様に最初から「仮に実際の規格に適合しないバグがあった場合は規格にあわせて修正される」って織り込んで、ドキュメントに「出力結果ではなく規格を参照せよ」って書いても良さそう＞＜
(言語のユーザーに早くバグを見つけて貰って早く修正しよう＆一部の責任をユーザーに押し付けよう作戦)
規格であっても SHOULD とか MAY による規定は条件や合理性次第では守らないことがありうるということになっているので、ちゃんと処理系側が具体的な話をしていかないと駄目
たとえば RFC 3339 の日時フォーマットで言うなら、年月日と時間を区切る T が大文字である必要があるか小文字でもいいのか、あるいは T 以外の文字でもいいのか、みたいなこととか。
ライブラリ側の仕様で「必ず規格にあわせるしあっていなければバグであり修正される」ってうたっておけば、例えばユーザーが書いたそこから得た文字列を処理するコードが規格通りの文字列を処理出来なければユーザーが悪いって事に出来るし、逆に規格外の文字列をライブラリが返せばライブラリが悪いとなるので、
ライブラリ側の開発者が「どうしよう！ 修正したら互換性が！」って悩まずに「ごめんなさいすぐ修正します！」って土下座からすぐに修正にとりかかれる＞＜
むしろ orange 氏は互換性重視サイドの人だと思ってたけどそうでもないのか
既存コードの想定した挙動を破壊するような変更を基幹ライブラリが導入することのリスク、基本的に予告の有無には全然関係ないので
PHP の mt_rand() は一貫して壊れている(consistently broken)らしい - 唯物是真 @Scaled_Wurm
https://sucrose.hatenablog.com/entry/2016/02/19/235506
これを思い出したりした
ソフトウェアが物理的メディアで流通されたりした時代や、ハードウェアの仕様であれば「規格の方を優先します！！！」って言っても「そんな簡単に修正出来ないだろ！」ってなって、バグというか実装にあわせてコード書くしかないけど、オンラインアップデートの時代で「バグはアップデートでなおせばおk！」って緩い時代である今のソフトウェアであれば、規格優先自体を仕様にするのもありかもって＞＜
PC ではそうだろうけど、いまや組み込みで Ruby が動いたりする時代だし、 “オンラインアップデートの時代” にあってオンラインアップデートを前提としない機器が一般の環境から乖離していくのは弊害がデカそう
べつに組み込みなんて最初から一般の環境から乖離してるだろと言われると、それはそうだけど
This account is not set to public on notestock.
声優の清川元夢さん、死去 87歳 『エヴァ』冬月コウゾウ役や『ナディア』ガーゴイル役など | ORICON NEWS
https://www.oricon.co.jp/news/2246734/
https://twitter.com/oricon_anime_/status/1561625338140307456
てことはごちうさに4期や劇場版があったらティッピーの声は違う人があてるのか……
互換性重視だけど規格を守るべきだしバグはバグなのでなおせ派なので、この場合、規格に合わせずに書いたユーザーのコードがバグってて姿勢が誤ってるので、明示的に「実装にあわせるな規格に合わせろ」って言ってるわけだから、そうしなければ明確にユーザーの責任かもって＞＜
> 規格に合わせずに書いたユーザーのコードがバグってて姿勢が誤ってる
そうなのかなぁ……
それこそ言語規格としてどこまで保証しているか次第な気がするけどな (まあ件の例について詳細を知らんので何とも言いがたいが)
PHP :: Bug #51950 :: DateTime does not handle decimal fractions of ISO 8601 format
https://bugs.php.net/bug.php?id=51950
そういう話か
まあ「正しかろうが間違っていようが、修正により脆弱性 (クラッシュの可能性含む) が導入されるようではサーバ実装に使われる言語として困る」というのはまったくもって合理的な判断だと思う (それが好きか嫌いかというのは別の話として)
よーするに今回の例であれば、 “修正” してしまうと今まで受理されなかった入力まで受け入れるようになってしまうので、もし一部を手動でパースしたり部分文字列を弄ったりなどのコードがあると当然そこが壊れるということになり、ダウンストリームの実装に DoS 攻撃の余地や、 FFI が絡むなら ACE 脆弱性を導入することになりかねない
好きでないし理想的でもないが、少なくとも secure な判断ではある
それはある程度それはそうで、元の話の事例でも実装の互換性を優先すべきだと思う＞＜
一方で「規格を優先せよ」方式であれば、「正しく作る」やり方(シンプルと正しいのどっちを優先するかでも言われてるやつ)との相性がよくなる気がするかも＞＜
(実際に安全かではなく)失敗したら人が死ぬ分野の開発のやり方に(ユーザーが)近くなるかもって＞＜
言うて規格だって後から訂正が入ったり穴があったりするわけで、結局どこまで挙動が安定するのかというのはかなり疑わしいと思っています
たとえば規格にデカい穴が見付かって、それに対して “広く合意されているが新標準としては発行されていない” ような独自修正を皆がそれぞれ当てるようなケースは十分現実的だろうし
処理系における保証の有無系でたまに見るコンテキストとしては、数値計算の精度とかですかね……