#if !GLIB_CHECK_VERSION(2,6,0) // if Glib is too old to have wrappers,
fall back to libc
#define g_freopen freopen
#define g_fopen fopen
#define g_rmdir rmdir
#define g_remove remove
#define g_unlink unlink
#define g_lstat lstat
#define g_stat stat
#define g_rename rename
#define g_open open
#end
Oh, I see. I guess whoever wrote the code decided the glib
wrapper functions weren't working right for MSDOS and wanted
to use fopen without the filename translation that glib does.
Well, he wasn't obligated to use the Glib functions. In fact, none of the g_
functions that are #define'd in fil
On Sun, 07 Sep 2008 21:16:30 +0400, Роман Донченко wrote:
>> These define statements are in the scope of
>> #if defined(G_OS_UNIX) && !defined(G_STDIO_NO_WRAP_ON_UNIX)
>> so they have effect only when compiling for MS Windows, essentially.
>
> In Glib code, yes. In Pan code, no. In fact, there'r
These define statements are in the scope of
#if defined(G_OS_UNIX) && !defined(G_STDIO_NO_WRAP_ON_UNIX)
so they have effect only when compiling for MS Windows,
essentially.
In Glib code, yes. In Pan code, no. In fact, there're no occurances of
G_OS_UNIX in Pan source.
On Sun, 07 Sep 2008 20:05:46 +0400, Роман Донченко wrote:
> #define g_fopen fopen
> This apparently has the intent of replacing the C functions with Glib
> functions when they are available, except... it's very broken because
> the #define arguments are in the wrong order. So even if you use Gli
So I checked the Pan source, and this is what I found:
1) pan2/pan/data/article-cache.cc, line 232:
~
fp = fopen (filename, "wb+");
~
The ~filename~ in question is in Glib's "filename encoding", which in
Windows in UTF-8. Obviously fopen~ can't cope with that. Fortunately Glib
includes the
