[freewnn:00832] Re: 標準の関数をどこまで仮定するか。

[aono@XXXX (Tomoki AONO)]

青野です。こんばんは。
＃検証するひまがありません…。それ以前に何を検証するのか、
＃というのもありますが。

引用で省略した部分はそれに対する意見を持ち合わせていない、
とお考えください。

<86eli5rjjv.wl@chrysanthe.oikumene.gcd.org>の記事において
hiroo@oikumene.gcd.orgさんは書きました。

>> おきかえ、configure の結果をもとに代替処理があるとよさそうなものは下記
>> のようなところでしょうか。思いつきなんで、もうちょっとよく考えないとい
>> けないと思っていますが。
>> 
>> ・index → strchr, bcopy → memmove, bcmp → memcmp に書き換え。

memcpyとmemmoveの違いはコピー元・コピー先領域が重なった時
のみだと記憶しています。一つ一つ検証する必要がありますが、
大抵の場合memcpyで代用できるものと(現時点では)考えています。

>> ・functions:
>>   memmove がない → bcopy を使う、で済むのか、
>>   memmove がない → bcopy がない → memcpy +αで代替処理、としないとなのか。

青野が考えていたのは#ifdefで分岐した中で、
#define memcpy(dst, src, n) bcopy(src, dst, n)

を書き加えること程度のことでした。どちらかはあることを前提
に考えていましたが、配慮が足らないかもしれません。

>> あとは、
>> ・malloc & free

もうパッチも提案されているのですが、意見表明だけしておきま
す。

>>   これは、GNU coding style に書いてあることにのっとって、
(略)
定式のようなものがあるのならそれに従う方がよいでしょう。

>>   で、wnn_malloc.h とか MALLOC.c とか削除出来るかな…と思っています。

MALLOC.cでしているのはプログラムミスを防ぐためのチェックが
入っているだけだと思うので、無理して外す必要もないのではな
いかと思います。wnn_malloc.h内のプロトタイプ宣言での条件分
岐は削除するべきですが。
＃もし残すとしてもxmalloc()とか、名前は変えておいた方がよ
＃いかもしれません。

その他のメールで小野さんが触れられていることについても簡単に。

(#include <unistd.h>)
これはconfigureで判別させればよいように思います。
＃これでBEOSの定義はしなくてもよくなるかな…?

(w_char)
仕様として存在しているとはいえ、wide charは実装依存の度合
いが大きい印象を持っています。個人的には触れない方がよいよ
うな気がします。

(msg_*)
現在のロケールに沿ってメッセージを切りかえるのは今風で便利
そうに思います。jutilでgettext()化するのも(先の話でもよい
のですが)よさそうに思います。

ただlibwnnの中でgettext()前提のコードにするのはクライアン
ト側でlibintl(ないしgettext() の存在するライブラリ)を判別
させる必要があるのでその辺りをどうするか考えてからでも遅く
ないと思います。
＃現時点ではやめといた方がよいのでは、という考えを持ってい
＃ます。

(今青野が考えていること)
リリースとはあまり関係なしで考えています。まだどれも実装ま
で進んでません。どなたかされる or その予定があるのならば止
めませんので(^^; パッチを投稿するなりcommitするなりして下
さい。

・ソースディレクトリと別のディレクトリでコンパイルできるよ
うにすること。
＃これが出来るとNFSなどで共有した環境で複数アーキテクチャ
＃のビルドが楽になります。

・TCP_wrappers(libwrap)サポートの「車輪の再発明」
＃すでにいくつかパッチは出ていますが、もう一工夫できないか
＃思案中です。

・max_client(jserverの接続数上限)
＃一応青野も関わった話なので、きれいな形で取り込みたいと思っ
＃ているのですが、まだコーディングにも行きついていません。
----
青野智樹	(aono@cc.osaka-kyoiku.ac.jp)
Personal opinion only...