GNOME Bugzilla – Bug 423147
client code compiles for GMime 2.2.5, or earlier, but not both
Last modified: 2007-03-28 13:04:17 UTC
http://svn.gnome.org/viewcvs/gmime/trunk/gmime/gmime-utils.h?view=diff&r1=1075&r2=1076 changes the header_encode and header_decode functions from uchar to char. This causes code that compiled on earlier versions to not compile: utf8-utils.cc:189: error: invalid conversion from ‘const guchar*’ to ‘const char*’ If I change my client code to work with 2.2.5, it no longer compiles with older versions: utf8-utils.cc:189: error: invalid conversion from ‘const char*’ to ‘const unsigned char*’ client code can probably be crafted to work with both versions via a GMIME_CHECK_VERSION() macro, but I doubt that's what you were aiming for with the change.
is this with -Werror or something? :( These s/unsigned char */char */g changes were to make gmime build with -Werror and on compilers that are a bit too pedantic for their own good :\
No, not with -Werror. CFLAGS is "-Wall -ggdb3 -Os"
I guess c++ is more fickle? :( oh phew, you are using the old deprecated interfaces... (looking at the code right now) I can totally change g_mime_utils_8bit_* functions back to const unsigned char * I'll do that right now... :) committed to svn, assuming no other problems - I can make a new 2.2.6 release (I've made some other fixes since my sunday release already anyway... 64bit largefile support, some uninitialized memory reads in gmime-gpg-context.c, etc)
The non-deprecated APIs have the same issue, but it's simpler to burn that bridge if/when someone complains. Pan will upgrade to the new APIs when 2.2 has been out for awhile longer. Thanks very much for the quick change.
Greetings C prorammers -- as an aside C++ has stricter type checking. In C for example you can always assign a void * to any pointer without a cast (sometimes you get a warning, but the language supports it officially). In C++, that is an error and requires a specific cast (a reinterpret_cast or a C-style case) to circumvent. All pointer types must match exactly -- singed char * vs unsigned char * is considered a completely different type and requires a cast. The same goes for const pointers, etc. Basically, it's a C++ thang. C++ just has stricter type checking. So -- if you like us C++ programmers at all, maybe in the future you can keep us in mind? ;)
heh, sowwy :) forgot pan2 was in c++... I haven't looked at pan code since it was in c - not that I would have known about the c++ thing anyway. oh well... I'm typically a pretty low-level hardcore c programmer that until recently didn't know what a high-level programming language was :p j/k... mostly. I'm hacking in c# these days tho, new job and all...
*** Bug 423313 has been marked as a duplicate of this bug. ***
Hey fejj, saw you in #pan on freenode -- too bad I missed you. No worries about the C++ thing -- and yes the new version of pan is a complete rewrite from scratch, and it's in C++. It's faster, consumes less memory, is more stable, and has a less complex and smaller codebase. It really is pretty sweet. I was amazed when I learned of its existence a few months ago.. I'm not saying it's *because* it's in C++ that it's so great -- it has to do with the nature of rewrites... throwing one away and starting over can be pretty good sometimes.. Anyway thanks for being sensitive to C++ needs. ;) Fortunately if people like Stroustroup get their way, C and C++ may be even more compatible in the future (one can always hope, although lots of people are opposed to this on philosophical grounds mainly).