On Wed, 2014-02-19 at 14:05 +0100, Tino Mettler wrote: > Hi Patrick, > > as the libsynthesis version was not bumped, am I right that > syncevolution 1.4 is compatible with libsynthesis from > libsynthesis_3.4.0.47+syncevolution-1-3-99-6?
Correct. There have been some changes and fixes, but none of them are really important. Probably the most important one is the "support sending NumberOfChanges" change, because that ensures that progress in percent can be reported for a local sync. Details: $ git log libsynthesis_3.4.0.47+syncevolution-1-3-99-6..libsynthesis_3.4.0.47+syncevolution-1-4 commit 17087c460472faeed2dc6679e186eee847b845a7 Author: Patrick Ohly <[email protected]> Date: Mon Jan 27 16:33:34 2014 +0100 debuglogger: close log file on exec When using fork+exec on Linux, open files get inherited by the child process unless explicitly marked as FD_CLOEXEC. We should set that flag at least for files which remain open (like the log file when dbgflush_openclose is not active). A truly thread-safe approach would have to use open(O_CLOEXEC), but setting the flag later is sufficient for us. This change is limited to Linux to avoid interfering with other platforms. commit 60c14f7816f674297bde11476d15f7a729185e94 Author: Patrick Ohly <[email protected]> Date: Fri Jan 24 08:44:33 2014 +0100 binfileclient: support sending NumberOfChanges In a binfileclient, the NumberOfChanges value became available to late to get included in the TSyncCommand when constructing that command. Even when it got calculated later in TBinfileImplDS::changeLogPreflight() it never got sent to the server. Making the value available earlier is not possible (changeLogPreflight depends on information calculated after generating the sync command), but it is possible to re-check the NumberOfChanges before continuing the sync in the next message. The result is a sync where the first several items are sent without NumberOfChanges, then the next message has NumberOfChanges. commit cbd03b0516c5a699604ef278781e9d458fad6530 Author: Patrick Ohly <[email protected]> Date: Wed Jan 8 05:13:13 2014 -0800 sysync_b64: avoid false positive with scan-build clang's scan-build warned: Result of 'malloc' is converted to a pointer of type 'uInt8', which is incompatible with sizeof operand type 'char'. This is not a real problem, because it is safe to assume that sizeof(uInt8) == sizeof(char). But better be explicit about what the code is supposed to do and use sizeof(uInt8). commit 07db39df146a63fcc3a2cbf9295b99d67f386458 Author: Patrick Ohly <[email protected]> Date: Wed Jan 8 05:09:55 2014 -0800 syncsession: track pointer clang's scan-build reported a "use after free" error. Probably a false positive, caused by clang not knowing that a function call will always return the same value. Nevertheless it is safer to really track whether the pointer is still non-null, in particular because there are exception handlers which might do a double free. commit 4265685eb93d28bcb6e21853131b51a89291bd5b Author: Patrick Ohly <[email protected]> Date: Wed Jan 8 05:07:28 2014 -0800 SyncML TK: fix invalid memory allocation Some unused code allocated memory sufficient for only for a *pointer* instead a *structure* as it should have done. Found by clang's scan-build, for example: Result of 'malloc' is converted to a pointer of type 'struct sml_filter_s', which is incompatible with sizeof operand type 'SmlFilterPtr_t' commit 38970617f539e6b08be4b2c81a211952aa52ced9 Author: Patrick Ohly <[email protected]> Date: Wed Jan 8 05:03:24 2014 -0800 enginesessiondispatch: additional NULL check HandleDecodingException() checks for aSessionP for NULL in some places, but not all. Found by clang. Let's assume that the function might get called with a NULL pointer and hence check for that everywhere. commit d89d803eee538bada7d7b2acd81ec28d28a83619 Author: Patrick Ohly <[email protected]> Date: Wed Jan 8 05:01:01 2014 -0800 binfileimplclient: simplify code flow analysis When the first if check fails, the second one also fails and thus it and its code only need to be executed when the first one succeeds. This is irrelevant for performance. The reason for changing it is that it avoids a false positive in cppcheck. commit c018d7a53b42e84fe8a6a124a9cebfd147d4b940 Author: Patrick Ohly <[email protected]> Date: Wed Jan 8 04:58:46 2014 -0800 fix delete/delete [] mistakes clang's scan-build found some more cases where delete was used instead of delete []. commit fc91177e218f5d6fcf9f80d34842bda4e658a226 Author: Patrick Ohly <[email protected]> Date: Mon Jan 6 23:45:32 2014 -0800 binfilebase: avoid virtual methods in destructor cppcheck complains about the virtual method call to platformFileIsOpen that happens indirectly inside the destructor if the instance has not been deconstructed. Because all derived classes must deconstruct the base class first (mentioned in the binfilebase comments), the base class destructor should never have to do anything. If it did, the program would crash. Therefore it is better to not even attempt to do anything in the destructor. commit b2bede775fe523c30c6b14366b49edac1384d3ff Author: Patrick Ohly <[email protected]> Date: Mon Jan 6 23:40:51 2014 -0800 fix new [] and delete mismatch Static code analysis with cppcheck found some cases where an array was allocated with new [] and freed with a simple delete instead of delete []. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ SyncEvolution mailing list [email protected] https://lists.syncevolution.org/mailman/listinfo/syncevolution
