GDAL windows 版は何を想定しているのか？

日本語対応の処方箋をogr2ogrに施してみたが、どうも、マシンによって挙動が異なるので、深追いしていました。そしたら、こんなコードにぶつかった。

int VSIStat( const char * pszFilename, VSIStatBuf * pStatBuf )

{
#if defined(WIN32) && !defined(WIN32CE)
    if( CSLTestBoolean(
            CPLGetConfigOption( "GDAL_FILENAME_IS_UTF8", "YES" ) ) )
    {
        int nResult;
        wchar_t *pwszFilename = 
            CPLRecodeToWChar( pszFilename, CPL_ENC_UTF8, CPL_ENC_UCS2 );

        nResult = _wstat( pwszFilename, (struct _stat *) pStatBuf );

        CPLFree( pwszFilename );

        return nResult;
    }
    else
#endif 
        return( stat( pszFilename, pStatBuf ) );
}

　これ、何を意図しているかというと、Windows 環境では、GDAL_FILENAME_IS_UTF8 = YES と環境変数に設定されている場合には、ファイル名等の文字コードを UNICODE(UCS2) wchar_t 型から、UTF8UTF8から、UNICODE（UCS2）wchar＿t型 に変更してあげましょうというコードになります。 　ところが、おかしいです。まず、細かい事ですが、defined(_WIN32) であって、defined(WIN32)では無い。次に、windows ce の場合は、UNICODEのアプリケーションを組む事になってたと思います。そろそろ windows ce はオワコンなんで、この部分は、もう関係無くなります。次に、そもそも現在は MBCS(Multi Byte Code Set)でコンパイルされているので、UNICODEであるはずがありません。前提条件が異なっている。仮に UNICODE でコンパイルしたとしたら、今度は、他のコードが大混乱に陥る事が容易に想像できます…。 　うーん・・・ここで MBCS を UTF8 に変換してあげても、既存のIO関係のコードが MBCS 前提で動いてたりすると、もうお手上げに近いですね。CPLFopen とか、CPLFclose CPLFseek みたいな関数を用意してあげないと、ちょっと厳しいですね。UTF8をUNICODEに変換する事で、ウィンドウズの文字コード問題を乗り切るという方針で組まれているようです。