新しいものを表示
orange さんがブースト

言うて規格だって後から訂正が入ったり穴があったりするわけで、結局どこまで挙動が安定するのかというのはかなり疑わしいと思っています

それはある程度それはそうで、元の話の事例でも実装の互換性を優先すべきだと思う><
一方で「規格を優先せよ」方式であれば、「正しく作る」やり方(シンプルと正しいのどっちを優先するかでも言われてるやつ)との相性がよくなる気がするかも><
(実際に安全かではなく)失敗したら人が死ぬ分野の開発のやり方に(ユーザーが)近くなるかもって><

orange さんがブースト

よーするに今回の例であれば、 “修正” してしまうと今まで受理されなかった入力まで受け入れるようになってしまうので、もし一部を手動でパースしたり部分文字列を弄ったりなどのコードがあると当然そこが壊れるということになり、ダウンストリームの実装に DoS 攻撃や、 FFI が絡むなら ACE 脆弱性を導入することになりかねない

スレッドを表示
orange さんがブースト

まあ「正しかろうが間違っていようが、修正により脆弱性 (クラッシュの可能性含む) が導入されるようではサーバ実装に使われる言語として困る」というのはまったくもって合理的な判断だと思う (それが好きか嫌いかというのは別の話として)

スレッドを表示
orange さんがブースト

それこそ言語規格としてどこまで保証しているか次第な気がするけどな (まあ件の例について詳細を知らんので何とも言いがたいが)

スレッドを表示
orange さんがブースト

> 規格に合わせずに書いたユーザーのコードがバグってて姿勢が誤ってる

そうなのかなぁ……

逆に、そういうことを明確に表明してなければ、実装の互換性を優先すべきだと思う><

スレッドを表示

互換性重視だけど規格を守るべきだしバグはバグなのでなおせ派なので、この場合、規格に合わせずに書いたユーザーのコードがバグってて姿勢が誤ってるので、明示的に「実装にあわせるな規格に合わせろ」って言ってるわけだから、そうしなければ明確にユーザーの責任かもって><

orange さんがブースト

既存コードの想定した挙動を破壊するような変更を基幹ライブラリが導入することのリスク、基本的に予告の有無には全然関係ないので

orange さんがブースト

むしろ orange 氏は互換性重視サイドの人だと思ってたけどそうでもないのか

ソフトウェアが物理的メディアで流通されたりした時代や、ハードウェアの仕様であれば「規格の方を優先します!!!」って言っても「そんな簡単に修正出来ないだろ!」ってなって、バグというか実装にあわせてコード書くしかないけど、オンラインアップデートの時代で「バグはアップデートでなおせばおk!」って緩い時代である今のソフトウェアであれば、規格優先自体を仕様にするのもありかもって><

ライブラリ側の仕様で「必ず規格にあわせるしあっていなければバグであり修正される」ってうたっておけば、例えばユーザーが書いたそこから得た文字列を処理するコードが規格通りの文字列を処理出来なければユーザーが悪いって事に出来るし、逆に規格外の文字列をライブラリが返せばライブラリが悪いとなるので、
ライブラリ側の開発者が「どうしよう! 修正したら互換性が!」って悩まずに「ごめんなさいすぐ修正します!」って土下座からすぐに修正にとりかかれる><

orange さんがブースト

たとえば RFC 3339 の日時フォーマットで言うなら、年月日と時間を区切る T が大文字である必要があるか小文字でもいいのか、あるいは T 以外の文字でもいいのか、みたいなこととか。

スレッドを表示
orange さんがブースト

規格であっても SHOULD とか MAY による規定は条件や合理性次第では守らないことがありうるということになっているので、ちゃんと処理系側が具体的な話をしていかないと駄目

こういうの、仕様に最初から「仮に実際の規格に適合しないバグがあった場合は規格にあわせて修正される」って織り込んで、ドキュメントに「出力結果ではなく規格を参照せよ」って書いても良さそう><
(言語のユーザーに早くバグを見つけて貰って早く修正しよう&一部の責任をユーザーに押し付けよう作戦)

orange さんがブースト
orange さんがブースト

あと、

➡️ここをクリックしてください

的な感じの事が書いてあって、その文字列だけ色がちがくなってる(たしか青だった気がする)けど、➡️部分(実際は文字より小さい)だけがリンクになってて文字列部分はただの表示とか・・・><

古いものを表示
:realtek:

思考の /dev/null