YamaKen
yamak****@bp*****
2005年 2月 15日 (火) 16:57:56 JST
At Tue, 15 Feb 2005 16:04:09 +0900, ekato****@ees***** wrote: > > On 2005/02/15, at 9:27, YamaKen wrote: > > ただ、_GNU_SOURCEの方は露骨に外部の非標準なglibc拡張をアテにして、 > > それに対する制御もソース中に書く事になるのが気持ち悪いと感じて先 > > のような提案をしてみました。最近はasprintf()をサポートしているシ > > ステムも多いですが、きちんと規格化されてない関数はなるべく使いた > > くないという意識があるので。例えばconstやNULLの扱いが実装によっ > > て違ってくる可能性もありますし。 > > _GNU_SOURCE を定義するのは特に問題無いと思いますけど。というかこれも古い > glibc で必要なのでしょうがないというか… > 挙動に関しては、asprintf がある、BSD や Linux では問題無いです。 ええと、うまく意図が伝わらなかったようですが、そもそも外部の asprintf()を使いたくないという話です。_GNU_SOURCEをdefineする事 自体に問題があるとは思っていません。_GNU_SOURCEに関係するような 非標準的な機能に依存したくないという事です。libuimでも昔から asprintf()は避けています。 なので常にuimが自前で持っているasprintf()を使う事にして、さらに conflictを避けるためuim_asprintf()のような名前にするのはどうでしょ う、という提案をしました。 もちろんこれの影響を受けるのは今のところuim-ximだけなので、加藤 さんのやりやすい方法で良いと思います。 私の言いたかったのは「いかにして多くのプラットフォームで asprintf()を使えるようにするか」よりも「いかにシステム側の asprintf()を使わずに実装するか」というアプローチを基本にした方が 少ない労力で高いポータビリティを確保できるんじゃないかという事で す。Windows CEでXが動いたりする時代ですし。 思いのほか長い話になってしまいましたが、そういう考え方もあるのか ぐらいに軽く受け取っといてください。 余談ですが、こういったポータビリティの確保はSchemeインタプリタに 任せて楽したい、という目論見もあって将来的にはlibuimのコードを可 能な限りScheme化したいと思っています。これにはcommitter間で異論 がありますが。 ------------------------------- ヤマケン yamak****@bp*****
