Re: [fetchmail-devel] fetchmail and mapi II

[Matthias A. <mat...@gm...>]

Am 09.07.2009, 06:43 Uhr, schrieb Yangyan Li <yan...@gm...>:

> Sorry for the messing up of branch MAPI, I will try to fix these
> issues one by one.

That sounds great. Thank you!

> Roughly speaking, I will concentrate on:
> 1. a complete review of the existing code, probably a rewriting is  
> required.
> 2. port this branch to match the latest libmapi release.
>
> In fact, I test on the Exchange Server inside my Virtualbox, it will
> be great if anyone can provide some testing environments.
>
> I will seek more advice from you during my development and welcome  
> opinions!

You're welcome to use the fetchmail-devel@ list for further questions. Use  
"MAPI" in the subject so that all interested parties will see your  
messages.

CONTENTS

I have merged the 6.3.10 release (from /branches/BRANCH_6-3) into  
BRANCH_MAPI, and merged Mojmir's patches where they looked sane, and fixed  
some minor configure.ac issues (see NEWS).

Do we really need libmagic for MAPI support? What exactly does it do?


SUBVERSION CHANGES

WRT the Subversion server:  I have had Graham (who maintains the server)  
enable mergeinfo tracking. The server now also locks out commits from SVN  
clients that are older than version 1.5.0, to make sure that no clients  
mess up the mergeinfo. (The server is version 1.6.X).

The bonus is that you no longer need to manually track which version you  
have merged, Subversion does that for you. It can't hurt to document the  
version, as you used to do :). Just make sure to only use "svn merge [-c  
M[,N...] | -r N:M ...] SOURCE[@REV] [WCPATH]" syntax.

If this feature is new for you, and you're looking for documentation, see  
for instance  
http://svnbook.red-bean.com/en/1.5/svn.branchmerge.basicmerging.html and  
the following sections and chapters.


COMPILE WITH WARNINGS

Could I ask you a favour? Can you configure with modified CFLAGS, for  
instance:

configure -C --with-ssl --enable-MAPI CFLAGS="-O -g -pipe -Wall -W -Wextra  
-pedantic"

(-W -Wextra is redundant, but covers older and newer GCC versions)

That enables some more warnings and helps find bugs - for instance, I  
found the sprintf() bug (around language code parsing) in rcfile_y.y that  
way.

Warnings of the "defined but not used" need not be fixed if you're sure  
that you haven't mistyped somewhere and actually meant to use the unused  
variables.

Signedness warnings should be double-checked and fixed by matching types -  
please do not add casts to silence the compiler!  These warnings are  
usually hints that something's wrong with the code, and a second thought  
needs to be spent especially on indexes and wraparound/overflow behaviour.


Thanks again!

Best regards

-- 
Matthias Andree