アカウント名:
パスワード:
これまでとの互換性を保つようなコンパイルオプションとか用意されてないのか？
定数領域をいじるなんて未定義動作なんだから、普通にソース直せばいいだけ
ソースがいじれないほど保守的な案件なのに、コンパイラは最新バージョンのLLVMに上げろって奇妙な指示があるなら別だが
理想を事も無げに言うだけじゃ、何も言ってないのと同じだわな
ソース直すのが理想なわけ？あんたんとこでは新しいコンパイラで顕在化したバグは直さないの？
頭でっかち派とどろどろ現場動かないと意味無い派の熱い戦いですね。理想と現実とどっちをとるかは人による。
ソース直さない人は最新バージョンのLLVMに上げるとか言わないんじゃね。
コンパイラは最新バージョンのLLVMに上げるがソース直すなって、理想でも現実でもなくて単なる阿呆ではないかと。というか、そんなやつが本当にいるのか？
現実派の人は今あるソースがコンパイルできて動かせてんだから、わざわざコンパイラだけ新しくするとか意味不明な手間かけないよw
ソース直すか今使ってるコンパイラを使いつづけるのって、業務用途の開発でも普通に選べる選択肢なんじゃねーの？
当たり前すぎて「何も言ってないのと同じ」ってならまだわかるが、「理想」って、そんな手の届かない世界のことみたいに聞こえるのか…。なんつーか、まぁ頑張れや。
それを普通に選べる選択肢にしておくためには、普段から普通レベルのプログラマの絶え間ない普通の努力が必要なのだ。
普通って理想だよな
使っている外部ライブラリに脆弱性が見つかったとかで、ライブラリのバージョンを上げなきゃららんけど、その新版のライブラリがより新しいバージョンのコンパイラを要求する。でも、開発担当者がすでに会社を去っているので、ソースコードに手を入れることは極力避けたい。なんてしがらみはソフトウェア開発ではよくおきる話よ。
まあ、外に出て世間を見てきなさい。
コンパイラ変えて動かなくなるってわかってて、その原因がソースのバグなら、「手を入れることを極力避けたい」としてもバグはなおすよね？ライブラリのバージョン上げて、インターフェース変えられても「手を入れることを極力避けたい」ソースに手を入れるよね？
極力避けたいってケースはあっても、バグだとわかってる部分をそのままにしたいってのは、もう保守しないしサポートも止めたらから使わないってものぐらいじゃないの？
「ソースコードに手を入れることは極力避けたい。」ってのは管理職の言い方だよな。純粋に工学的には、コンパイラバージョンを変えたことで動かなくなったら少なくとも動作検証から全部やり直しが当たり前。だってコンパイラなんてカオスな系で、こんな風に動作が違えば「全く違う環境」なんだから。
「なんとか小手先で誤魔化して…」というのは「工学的には何の保証もないが、ビジネス的皮算用では人が死ぬわけじゃなし許容リスクとする」っつー話で、「清濁併せ呑んだ結果オッケーなんです」ってのは説明をサボってるだけなんだよな。
> その原因がソースのバグなら
それはアプリケーション側のソースコードのバグじゃないよね。
コンパイラ処理系、あるいはコンパイラの仕様バグだったもので、そのバグありコンパイラの環境上で動くアプリケーションのコードを書いてしまって、それでこれまで滞りなく動いていたんだから。
「動いてるものを直すな」ってのは、この世界じゃ鉄則だろう。
未定義動作に何かしらの期待をしているソースコードがバグだって言われてるのになぜ解らないのか
そのソフトそのものに脆弱性が見つかったときはどうすんのかね？ソースに手を入れずに直すのか？
>そのソフトそのものに脆弱性が見つかったときはどうすんのかね？
・運用でカバーする。(回避方法を伝える：大抵は無料)・対策済みの新機種(バージョン)を勧める(有料：割引ぐらいはあるかも)・保守契約を結んでパッチを当てて貰う。(パッチ自体は無料：保守費用は別途)・改修を新規案件として受注する。(確実ではあろうが、一番高価)・ラッパーを被せて脆弱性が発生する条件をフィルタする。(寸志：飲み代、飯代程度で個人的にお願いする)・営業が「このくらい簡単に治せますよ」と安請け合いする。(自腹、持ち出し)
じゃ、外部ライブラリの脆弱性も同じようにすればいいんじゃね。
そのケースなら別々にコンパイルしてリンクするだけだろwまぁ技術力が足りなくて無駄な苦労をしてる奴はよくいるよなぁ
リンクのインターフェースが変わるから、コンパイラのバージョンを合わせなきゃならんのだが。話わからんのなら、無理に割り込まんでいいよｗ
まぁできないパターンはいくらでも挙げられるしなゴクローサンだわ
未定義の動作に期待しておいて何を言ってるんだか。。。
「普通に」って付ければ何でも0コストになるように語る人ですね。こないだ入門書が話題になったナントカさんみたいに、C++の規格を偏重しすぎると現場に届かなくなる…。
リリースされたばっかのコンパイラなんか使おうってやつがコストとか言ってんじゃねーよｗセキュリティパッチじゃないんだから、最新のバージョンに飛びつく意味なんて全然ない
まあそうだなコストを払うべきはCMakeでダウンロードされるあらゆるプロジェクトのささいな仕事だ
いつまでもリリースされたばっかのコンパイラというわけではないでしょうに
警告もsegmentation faultも起こさず一見動いているように見えると、そういうバグを持っているとすら気がつかないだろうに。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲを呼ぶ -- ある傍観者
「今まで発生していなかった不具合が生じる可能性」 (スコア:0)
これまでとの互換性を保つようなコンパイルオプションとか用意されてないのか？
Re:「今まで発生していなかった不具合が生じる可能性」 (スコア:1)
定数領域をいじるなんて未定義動作なんだから、普通にソース直せばいいだけ
ソースがいじれないほど保守的な案件なのに、コンパイラは最新バージョンのLLVMに上げろって奇妙な指示があるなら別だが
Re: (スコア:0)
理想を事も無げに言うだけじゃ、何も言ってないのと同じだわな
Re: (スコア:0)
ソース直すのが理想なわけ？
あんたんとこでは新しいコンパイラで顕在化したバグは直さないの？
Re: (スコア:0)
ソース直すのが理想なわけ？
あんたんとこでは新しいコンパイラで顕在化したバグは直さないの？
頭でっかち派とどろどろ現場動かないと意味無い派の熱い戦いですね。
理想と現実とどっちをとるかは人による。
Re: (スコア:0)
ソース直さない人は最新バージョンのLLVMに上げるとか言わないんじゃね。
コンパイラは最新バージョンのLLVMに上げるがソース直すなって、理想でも現実でもなくて単なる阿呆ではないかと。というか、そんなやつが本当にいるのか？
Re: (スコア:0)
現実派の人は今あるソースがコンパイルできて動かせてんだから、
わざわざコンパイラだけ新しくするとか意味不明な手間かけないよw
Re: (スコア:0)
ソース直すか今使ってるコンパイラを使いつづけるのって、
業務用途の開発でも普通に選べる選択肢なんじゃねーの？
当たり前すぎて「何も言ってないのと同じ」ってならまだわかるが、
「理想」って、そんな手の届かない世界のことみたいに聞こえるのか…。
なんつーか、まぁ頑張れや。
Re: (スコア:0)
それを普通に選べる選択肢にしておくためには、
普段から普通レベルのプログラマの絶え間ない普通の努力が必要なのだ。
Re: (スコア:0)
普通って理想だよな
Re: (スコア:0)
使っている外部ライブラリに脆弱性が見つかったとかで、ライブラリのバージョンを上げなきゃららんけど、
その新版のライブラリがより新しいバージョンのコンパイラを要求する。
でも、開発担当者がすでに会社を去っているので、ソースコードに手を入れることは極力避けたい。
なんてしがらみはソフトウェア開発ではよくおきる話よ。
まあ、外に出て世間を見てきなさい。
Re: (スコア:0)
コンパイラ変えて動かなくなるってわかってて、その原因がソースのバグなら、「手を入れることを極力避けたい」としてもバグはなおすよね？
ライブラリのバージョン上げて、インターフェース変えられても「手を入れることを極力避けたい」ソースに手を入れるよね？
極力避けたいってケースはあっても、バグだとわかってる部分をそのままにしたいってのは、もう保守しないしサポートも止めたらから使わないってものぐらいじゃないの？
Re: (スコア:0)
「ソースコードに手を入れることは極力避けたい。」ってのは管理職の言い方だよな。
純粋に工学的には、コンパイラバージョンを変えたことで動かなくなったら少なくとも動作検証から全部やり直しが当たり前。
だってコンパイラなんてカオスな系で、こんな風に動作が違えば「全く違う環境」なんだから。
「なんとか小手先で誤魔化して…」というのは「工学的には何の保証もないが、ビジネス的皮算用では人が死ぬわけじゃなし
許容リスクとする」っつー話で、「清濁併せ呑んだ結果オッケーなんです」ってのは説明をサボってるだけなんだよな。
Re: (スコア:0)
> その原因がソースのバグなら
それはアプリケーション側のソースコードのバグじゃないよね。
コンパイラ処理系、あるいはコンパイラの仕様バグだったもので、
そのバグありコンパイラの環境上で動くアプリケーションのコードを書いてしまって、
それでこれまで滞りなく動いていたんだから。
「動いてるものを直すな」ってのは、この世界じゃ鉄則だろう。
Re: (スコア:0)
未定義動作に何かしらの期待をしているソースコードがバグだって言われてるのになぜ解らないのか
Re: (スコア:0)
そのソフトそのものに脆弱性が見つかったときはどうすんのかね？ソースに手を入れずに直すのか？
Re: (スコア:0)
>そのソフトそのものに脆弱性が見つかったときはどうすんのかね？
・運用でカバーする。(回避方法を伝える：大抵は無料)
・対策済みの新機種(バージョン)を勧める(有料：割引ぐらいはあるかも)
・保守契約を結んでパッチを当てて貰う。(パッチ自体は無料：保守費用は別途)
・改修を新規案件として受注する。(確実ではあろうが、一番高価)
・ラッパーを被せて脆弱性が発生する条件をフィルタする。(寸志：飲み代、飯代程度で個人的にお願いする)
・営業が「このくらい簡単に治せますよ」と安請け合いする。(自腹、持ち出し)
Re: (スコア:0)
じゃ、外部ライブラリの脆弱性も同じようにすればいいんじゃね。
Re: (スコア:0)
そのケースなら別々にコンパイルしてリンクするだけだろw
まぁ技術力が足りなくて無駄な苦労をしてる奴はよくいるよなぁ
Re: (スコア:0)
リンクのインターフェースが変わるから、コンパイラのバージョンを合わせなきゃならんのだが。
話わからんのなら、無理に割り込まんでいいよｗ
Re: (スコア:0)
まぁできないパターンはいくらでも挙げられるしな
ゴクローサンだわ
Re: (スコア:0)
理想を事も無げに言うだけじゃ、何も言ってないのと同じだわな
未定義の動作に期待しておいて何を言ってるんだか。。。
Re: (スコア:0)
「普通に」って付ければ何でも0コストになるように語る人ですね。
こないだ入門書が話題になったナントカさんみたいに、
C++の規格を偏重しすぎると現場に届かなくなる…。
Re: (スコア:0)
リリースされたばっかのコンパイラなんか使おうってやつが
コストとか言ってんじゃねーよｗ
セキュリティパッチじゃないんだから、最新のバージョンに飛びつく意味なんて全然ない
Re: (スコア:0)
まあそうだな
コストを払うべきはCMakeでダウンロードされるあらゆるプロジェクトのささいな仕事だ
Re: (スコア:0)
いつまでもリリースされたばっかのコンパイラというわけではないでしょうに
Re: (スコア:0)
警告もsegmentation faultも起こさず一見動いているように見えると、そういうバグを持っているとすら気がつかないだろうに。