[SyncEvolution] SyncEvolution 1.4 released

Wed Feb 19 14:17:29 UTC 2014

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 <patrick.ohly at intel.com>
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 <patrick.ohly at intel.com>
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 <patrick.ohly at intel.com>
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 <patrick.ohly at intel.com>
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 <patrick.ohly at intel.com>
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 <patrick.ohly at intel.com>
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 <patrick.ohly at intel.com>
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 <patrick.ohly at intel.com>
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 <patrick.ohly at intel.com>
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 <patrick.ohly at intel.com>
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.