木村です．

# 横から失礼．

--- On Fri, 03 Oct 2003 13:06:34 +0900,
	Hiroyuki Yamamoto <hiro-y@xxxxxxxxxx> wrote:

> > 私も以前同じ現象に悩まされましたが、isspaceなどがlocaleに依存して動作
> > が変わってしまう??ことが原因のようです。
> > 「[sylpheed-jp:02146] Re: 件名の文字化け」にも書きましたが、次のやり方
> > で回避できました。
> > 
> > > 1. 適当な所に空っぽのctype.hを作る。(touch ctype.h)
> > > 2. 強制的に1をインクルードさせる。(make CC='gcc -include ctype.h')
> > 
> > あるいは、[sylpheed-jp:02148]で吉山さんが報告されたやり方もあるようで
> > す。
> > 
> > >   環境は違いますが、他でも問題になっていました。解決策として、使用前
> > >   に
> > > isspace を undef してしまうというのがあるようです。
> > > 
> > > http://sources.redhat.com/ml/cygwin/1998-09/msg00550.html
> 
> こういう問題があるので、マルチバイト文字を扱うところでは isspace() を
> 使わずに自前で処理したほうがいいんでしょうかねぇ。
> grep isspace src/*.c したらかなりの量が引っかかるので思案中^^;

本現象はマルチバイト文字を扱うかどうかとは直接の関係が無く，locale と
glibc (+ ctype.h) の関係だと思います．
私が出会ったのは (自作のアプリですが…)，マルチバイト文字を扱っていない
のに isspace() が誤動作するというものでした．(なんと 0x20 が isspace()
で false になってしまった)
# ctype.h に定義されているマクロが悪いというよりも，glibc に埋め込まれ
# ている bit test テーブルがおかしいように見えた．glibc のバージョンに
# よっても違うかもしれません．

マクロ版の isspace() ではなくライブラリ関数版の isspace() では問題なく
動くようなので，isspace の undef というのは現実的な解だと思います．

或いは ctype.h のインクルードの際に

  #if defined(__GLIBC__)
  #define __NO_CTYPE
  #endif
  #include <ctype.h>

をするとか，locale の影響を受けないように見える isblank() に redefine
してしまうのもいいかもしれません．(isblank() は glibc の拡張みたいです
が…)