[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[fol] Re: Incorrectly built binary which accesses errno or h_errno directly. Needs to be fixed.を消すには?


kono@xxxxxxxxxxxxxxxxx (Shinji KONO) writes:

> thread safe にするなら大域変数は見直すのが当然なんで、どうし
> て、errno だけ特別扱いしてソースレベルの互換性を残したのかは、
> 僕は不思議に思いますけどね。一方でバイナリ互換は捨てるわけだし。

ソースレベルでもバイナリレベルでもずっと互換性が取れているのでは。
(*__errno_location())になったのがいつかは知りませんが、それ以降のバ
イナリはずっと動くじゃないですか。(おそらく、あまり古いバイナリだと、
他の原因で今のglibcでは動かないだろうけど。) 

# ところで、上で「ソースレベルの互換性を残した」のは「C言語の規格策定
# 者」でしょうが、「バイナリ互換は捨て」た(と河野さんが思った)のは別の
# 人ですよね?  別の人なのに「一方で」っておかしくない?)

もしerrnoのAPIを変えたとしたら、ソースもバイナリも非互換になってしまう。
たしかにerrnoという「変数みたいに見えるマクロ」は汚らしいですが、互換
性を保つ手段があるのにわざわざ変えることもないという判断は、まあ妥当だ
と思います。

河野さんはいったい誰に文句を言っているのか良く分からないわけですよ。
1.16年前のC言語の規格策定者
2.高速なTLSアクセス機能を実装したGCC開発者
3.バグのあるバイナリを更新しないSynopsys
4.16年間のバグフィックスの猶予を与えてがんばってきたGLIBC開発者

3ならわかるんだけどさ。他は、16年もたってなんで今さら…という感じ。

> > へえ。新しいLinuxは全部動かないんですか? RedHat (Fedra) でも?
> 
> 動かないのは一部の機能なので、それ以外の部分は動いてます。
> 要するに source に extern int errno; って書いてあるわけで、
> 僕達はそこには手を出せないから、外でなんとかしないと...

まあ、glibcの旧バージョン(あるいは--without-tlsでconfigureしてコンパイ
ルした最新バージョン)を入れて、そのソフトだけは特製glibcをPRELOADする
ようにwrapperを書くんでしょうかねえ。

				前田敦司

$B$3$N>pJs$,$"$J$?$NC5$7$F$$?$b$N$+$I$&$+A*Br$7$F$/$@$5$!#(B
yes/$B$^$5$K$3$l$@!*(B   no/$B0c$&$J$!(B   part/$B0lIt8+$D$+$C$?(B   try/$B$3$l$G;n$7$F$_$k(B

$B$"$J$?$,C5$7$F$$?>pJs$O$I$N$h$&$J$3$H$+!"$4<+M3$K5-F~2<$5$!#FC$K!V$^$5$K$3$l$@!*!W$H8@$&>l9g$O5-F~$r$*4j$$7$^$9!#(B
$BNc(B:$B!VJ#?t$N%^%7%s$+$i(BCATV$B7PM3$G(Bipmasquerade$B$rMxMQ$7$F(BWeb$B$r;2>H$7$?$>l9g$N@_Dj$K$D$$F!W(B
References: