[sylpheed:34897] Re: Crash in MSVC debug-mode

[Gisle Vanem]

"Gisle Vanem" <gvanem at broadpark.no> wrote:

> The 'fp' comes from Glib build in non-debug mode and the local
> fgets() is in debug-mode. How can we code around this? Is there no
> g_fgets()?

I'm replying to my own more than 1 year old message. Since there 
has been no fix for building Sylpheed using MS Visual-C in that time, I
got back to the problem some days ago. And I think I found a suitable fix.

First, the main problem is mixing libraries/DLLs built using different
C-runtime libraries. E.g. my versions of OpenSSL and Glib are built as
release. Hence the internal structure of 'FILE' are different. So when 
Sylpheed does things like (from ssl_init(), ssl.c):

  if ((fp = g_fopen(certs_file, "rb")) != NULL) {
    X509 *cert;
...
    while ((cert = PEM_read_X509(fp, NULL, NULL, NULL)) != NULL)
      trust_list = g_slist_append(trust_list, cert);
  fclose(fp);

This is just asking for trouble since PEM_read_X509 (OpenSSL) and 
g_fopen (Glib) could probably be expecting different layout of 'FILE'.
The fix could be to use BIO_new_file() instead of g_fopen(). That way
the structure of 'FILE' is keept privately inside the OpenSSL libs. I wish
there was an easy way of figuring out such problems at run-time.

Same problem with g_open(); since Glib wasn't build in _DEBUG-mode,
passing a 'fd' from Glib to close() in Sylpheed, raises an abort-dialogue 
since the 'fd' wasn't created in Sylpeed. And there is no g_close() either. 
Sigh!

So an ugly fix is to '#undef g_fopen' and g_open after we pull in <glib.h> and
<gstdio.h>. I've done this in my generated msvc/config.h. So everything seems
to work for MSVC now. Ref my page at:
http://home.broadpark.no/~gvanem/misc/#sylpheed

Any of this is no problem on MingW since it uses the same C-runtime
(MSVCRT.DLL) for all external libraries. And it has no debug/release
version clashes. We should discuss these things before I provide some 
patches.

--gv