The remaining warnings are either not valid or refer to code which
is intentionally broken. Suppress these warnings.
SyncEvolution now passes scanning with cppcheck 1.61 without warnings.
The intention is to get rid of the historic and inconsistent
naming of some classes and their corresponding files:
* EvolutionSyncClient = class derived from Funambol's SyncClient,
* SyncEvolutionConfig = SyncEvolution's config
With the strict 'namespace SyncEvo' and the syncevo/ path prefix for
most header files it is no longer necessary to have "SyncEvolution" or
"Evolution" in the names. This patch thus renames as follows:
EvolutionSyncClient => SyncContext
EvolutionSmartPtr => SmartPtr
SyncEvolutionCmdline => Cmdline
SyncEvolutionConfig => SyncConfig
SyncEvolutionUtil => util
The former EvolutionSyncClient always had a role that went beyond just
running a sync, for example it also provided config access. With the
upcoming server support it also won't be just a client. Thus the new
name "SyncContext".
The 'syncevo/' prefix is used throughout the code now.
removed whenever the prefix made it clear that the file belongs
to SyncEvolution. This helps finding incorrect include paths.
Quotes should be used exclusively for SyncEvolution files which don't
have a specific prefix yet (test.h, config.h) to help identifying
them.
Added syncevo/declarations.h, which has
This is now used for all SyncEvolution source files, except
for the GTK UI, which is written in plain C. In the library
it helps to avoid name clashes.
The reason for using defines instead of spelling out "namespace SyncEvo"
is twofold:
1. if that should ever become necessary, it is easier to
rename the namespace via configure options by changing
the define
2. editors don't indent the whole file content
Catch fatal signals (SIGSEGV, SIGABRT, SIGBUS) and in the signal
handler, flush and process output.
Flushing is done each time redirection is removed and thus
also catches output that is pending in either C or C++ output
streams during a normal application shutdown.
The abort-redirect test program covers such a scenario. It does
a double free, which depending on libc causes a segfault or
error message. The source is in "test" (like the rest of the
test programs) while the binary is built with "make abort-redirect"
in "src". It would be nicer if the test folder was a subdirectory of
src and wouldn't require its own Makefile, but that's a different issues...
Note that glib's double free report is written to the console
regardless whether stdout/stderr redirection is enabled. It seems
that glibc does not use FDs 1 or 2 for that, redirecting them in
the shell has no effect either. Catching the signal and flushing
is useful nevertheless.
