プロフィール

kosaki

Author:kosaki
連絡先はコチラ

ブログ検索
最近の記事
最近のコメント
最近のトラックバック
リンク
カテゴリー
月別アーカイブ
RSSフィード
FC2ブログランキング

スポンサーサイト このエントリーをはてなブックマークに追加

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。


スポンサー広告 | 【--------(--) --:--:--】 | Trackback(-) | Comments(-)

ioctl の man page が fix された このエントリーをはてなブックマークに追加

Linuxでは ioctlは

/usr/include/sys/ioctl.h:
extern int ioctl (int __fd, unsigned long int __request, ...) __THROW;

というプロトタイプになっているんだけど、なぜか manでは

int ioctl(int d, int request, ...);

と書いてあり、一致していないという問題があった。
実装がBSD互換で、manがOpenGroupのSUS準拠だったわけだね。

わたしがmanの問題だとおもって2012年1月にmanにチケットきったんだけどほうちされてて、

https://bugzilla.kernel.org/show_bug.cgi?id=42705

2012年7月にはLinusが glibcの実装の方を直すべきと主張して、glibcのほうにチケットを発行、

http://sourceware.org/bugzilla/show_bug.cgi?id=14362

どうなるのかやきもきしていたが、Michael 的にはmanは実装と一致すべきと思ったのだろう、
manを変更したとの連絡がとどいた。

これで使用法誤解がへるといいな。

以下、技術的および歴史的な状況の解説

・当初、ioctlはPOSIXに含まれていなかったのでBSD系は引数がunsigned long, SYSV系がintと分裂してた。
・glibcは、すごく昔の段階で多数派のBSDに日和った
・STREAMSをPOSIXに含めるときにioctlがPOSIXに追加された。しかし、それは(規格上は)STREAMS専用インタフェースで他の用途はしらんがな状態。かつ最新の規格ではSTREAMSはすでにobsolete
・世間の大多数のソフトは引数をintだと決め打っている。Macに至ってはカーネルが(BSD互換なので)unsigned longなのに、システムコンポーネントが int だと思って処理しているような箇所があり、

int action = (level ? TIOCSBRK : TIOCCBRK);
...
ioctl(fd, action, ...);

というコードが符号拡張で0xFFFFFFFF.... となってしまって、常に ENOTTY になってしまう有り様だった(Linusいわく)

・Linuxでは、そういうアホなユーザーランドへの対策として、64bitでも上位32bitは無視しているのでこの問題はおきない。たとえ、同様のミスをユーザーランドがしたとしても
・これをもって、Linusはカーネルはintでいいようになっていると主張していたが、manのほうのチケットでDavidが指摘したように、実際には最上位ビットも使っているので unsigned int 相当の動きをしている(Linusは暗黙の変換でうまくいくと主張していたが、まあ、そこはそれ)
・Linus的には 「So please fix the ioctl() declaration. "unsigned long" is misleading and actively incorrect and can cause bugs on non-Linux operating systems.」とglibcが直したほうが、よそのOSでのバグがなくなるんだと主張していたが、glibc関係者からは「Macにアホなバグがるから、glibcを直せってのはロジックが無茶苦茶だ」という反発がじゃっかんあったりなかったり。

とかなんとか迷走していた。
なお余談だが、Rubyもまったく同じバグが最近まであったのだが、1.9.3でわたしが直した。

備忘録なので、このエントリに特に結論はない。
関連記事


linux | 【2013-11-18(Mon) 18:49:24】 | Trackback:(0) | Comments:(0)
  1. 無料アクセス解析
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。