『Dr.WEB メールデーモン』、MTA 用迷惑メール対策製品です！
「数値的なホスト名を getaddrinfo に渡した場合には ai_canonname はセットされないのが仕様であるように見える」んですか。実はそれを確認するのが恐くてFreeBSDのソースに当たれないでいるのです。
とすると、RubyのSocket#gethostbynameのような、通常のホスト名からも数値的なホスト名からも、 区別なくホスト情報を得たい場合にはどうするのが正統なんでしょうねえ、FreeBSDにおいて。
素直にgethostbyname(3)を使うのはsocket.cにあるitojunさんがIPv6対応した時の
/* * NOTE: using gethostbyname() against AF_INET6 is a bad idea, as it * does not initialize sin_flowinfo nor sin_scope_id properly. */
というコメントを見る限り避けた方が良さそうな気がするし。
NokiaがケータイにPerlを載せてしまおうと計画しているという話。
組み込みにはPythonかLuaくらいがせいぜいと考えていたのだが、Perlが載るならなんだって載るぞ。 それこそRubyでも。
「getnaminfo(3)を使えば良いのでは?」というツッコミをもらったが、 私がやりたいのは別に逆引きがやりたいわけではないのだが。 繰り返しになるが、私がしたいのは、 「通常のホスト名からも数値的なホスト名からも、区別なくホスト情報(hostent)を得たい」ことである。 これくらいgetaddrinfo(3)がやってくれてもバチは当たらないと思うんだけどなあ。
これをgetnameinfo(3)を使って実現するためにはどうすればよいのは私にはいまいちわからない。 どういう手順を想定しているのかな。
「それを現状に甘んじているから搾取されるんだ。」とありますが、このあたりについて声を上げられるかどうかは当人の資質もあるんでなんとも言えない気も…。 今いる会社を離れて果たして食っていけるか？ということを気にする人も（たぶん）多いでしょうし、自分の資質や市場価値を過小評価している人も多い気がするんですが（汗）。 クチをあけてまってるだけの人は放置してOKだと思うんですが、自分の存在証明（そして価値証明）を何らかの形で実施している人のところには、そういう向きの会社が積極的にアプローチしてもよいと思います。
まあ気持ちはわかるんですが、
ことを考えると、最初の一歩を踏み出すのは本人以外にはあり得ないように思います。 結果的に「現状に甘んじている」人を第三者が助けることはできないでしょう。
はっきり言えば、 オープンソース技術者は、ヘッドハンティングしなければならないほどには売手市場ではない現実を考えると、 「そういう向きの会社からの積極的にアプローチ」を期待するのは、 現時点では「クチをあけてまってるだけ」とほぼ同じだと思います。
This work is licensed under a Creative Commons License.
既に指摘がある通り getnaminfo(3) を使えば良いのでは?
Solarisなんかだと 数値アドレス文字列 + AI_CANONNAME の組み合わせでは ai_canonnameフィールドには数値アドレス文字列がそのまま入るので, 成功してて ai_canonname がNULLなら元の文字列(のコピー)を使う, とかでもいいと思います。<br><br>どうもあちこちの様子を見てると<br> 数値形式アドレス文字列 + AI_CANONNAME <br>というのは getaddrinfo(3) では想定外の使い方のようです。<br><br>上で指摘されている getnameinfo(3) を使う場合ですが,getaddrinfo して, 成功してかつai_canonnameがNULLならai_addr を getnameinfo に渡してホスト名を得る、ということではないでしょうか。
s/wakatnono/wakatono/
同上ですが、τ森さんの書かれた通りだと思います。<br><br>アプリケーションの要求として、「通常のホスト名<br>からも数値的なホスト名からも、区別なくホスト情報<br>(hostent)を得たい」というのはちょっと変だと思い<br>ます。アプリケーションがふつう要求するのは、<br>「ホスト名ないし数値的なホスト名からアドレスを<br>得たい」と「アドレスから名前を得たい」というと<br>いう2種類の機能でしょう。前者を提供するのが<br>getaddrinfo(3)、後者を提供するのがgetnameinfo(3)な<br>わけですが、前者に対して、名前まで期待しているので<br>こういうことになっているのだと思います。<br><br>IPに対してai_canonnameとして期待される値は、FQDN<br>です。Solaris のやっているような数値アドレス文字列<br>をそのまま ai_canonname に返すやり方は、この点で<br>問題があるわけです。名前サービスとして DNS を利用<br>している場合に、数値アドレス文字列から、ai_canonname<br>として本来期待されている結果である FQDN を得るには、<br>逆引きを行うしかありません。しかし、逆引きは時間的<br>コストのかかる操作ですし、また逆引きが不可能である<br>ことも良くありますから、getaddrinfo(3) がこのように<br>動作するのも、当然のことながら、まずいわけです。<br><br>なお、最近の UNIX 系 OS では、gethostbyname(3) に<br>対して数値的なホスト名を与えると、成功して h_name<br>に、その数値的なホスト名がそのまま返ってくるものが<br>多いわけですが、これは BSD Net2 リリースの頃に導入<br>された比較的新しい機能です。たとえば 4.3BSD-tahoe<br>の頃の gethostbyname(3) は、このような要求に対して、<br>単に失敗を返していました。従って、gethostbyname(3)<br>のこの機能に依存するのも、広い意味での移植性の点で<br>は問題があります。