1. 26 Feb, 2019 1 commit
  2. 16 Jan, 2019 1 commit
  3. 06 Nov, 2018 1 commit
  4. 31 Oct, 2018 1 commit
  5. 06 Sep, 2018 1 commit
  6. 24 Apr, 2018 2 commits
  7. 06 Apr, 2018 1 commit
  8. 24 Mar, 2018 1 commit
    • Mats Wichmann's avatar
      static analysis: unintitialized struct · 9497dde7
      Mats Wichmann authored
      A couple of instances in this file do not initialize a struct,
      while the majority do so using memset. Aligned so this source file
      does things consistently. Two of these (lines 709 and 748 in the
      original source) are causing Coverity static checker complaints
      ("uninitialized scalar variable") because the struct is assigned -
      even though the member in question is never actually accessed.
      Note according to my understanding, for c++ code, it is considered
      better to use object initialization, although if the data is
      only POD (Plain Old Data), the result does come out the same.
      Thus, instead of:
          CAInfo_t responseData;
          memset(&responseData, 0, sizeof(CAInfo_t));
      it is suggested to use:
          CAInfo_t responseData {};
      we could adjust that in a separate change if people agree.
      It should not actually be necessary to pre-fill the whole struct
      with zeroes since the fields that matter get values in the tests
      before use anyway. However the problem with CAInfo_t is that
      someone thought it was a sensible idea to have a conditional
      field in an important (public API) struct in cacommon.h:
      typedef struct
          CAMessageType_t type;       /**< Qos for the request */
      .#ifdef ROUTING_GATEWAY
          bool skipRetransmission;    /**< Will not attempt retransmission even if type is CONFIRM.
                                           Required for packet forwarding */
          uint16_t messageId;
      } CAInfo_t;
      which means every valid use of CAInfo_t has to have the same #ifdef
      ROUTING_GATEWAY bracketing to deal with this optional member. This
      is absolutely horrid in a public API and should never happen -
      it means the API is different if you use different compile flags.
      Change-Id: If178c7d245142e166fa33447cd00946cff4a56fc
      Signed-off-by: default avatarMats Wichmann <mats@linux.com>
  9. 07 Mar, 2018 1 commit
  10. 02 Mar, 2018 1 commit
  11. 24 Jan, 2018 1 commit
  12. 14 Dec, 2017 1 commit
    • Mats Wichmann's avatar
      Remove arduino support 2/3 · 29144368
      Mats Wichmann authored
      Arduino is now supported only in iotivity-constrained,
      but all the support in the iotivity build remains.
      Remove in three phases (just to make shorter commits
      to review).  Part 2 removes arduino from all the other
      build scripts which referenced it, and from auto_build.py
      and the vagrant setup.
      Change also removes the remaining arduino directories, as
      which means some code files are removed as well.
      Bug: https://jira.iotivity.org/browse/IOT-2927
      Change-Id: Idd5001a810ff4f67022f60bcb9d3252f7de7ccc2
      Signed-off-by: default avatarMats Wichmann <mats@linux.com>
  13. 15 Nov, 2017 1 commit
  14. 14 Nov, 2017 1 commit
  15. 13 Oct, 2017 1 commit
  16. 05 Oct, 2017 1 commit
    • Mats Wichmann's avatar
      builds: stop defeating Variant dir Part 1/3 · bd555d18
      Mats Wichmann authored
      In various places in the build scripts, steps are taken which defeat the
      intent of using a variant dir: a distinct tree where building takes place.
      Mostly this works as expected, but in places where the scripts call
      Python facilities directly to figure paths out, scons does not have
      the ability to "know" the paths and do the internal substitutions if
      VariantDir is in effect.
      There is a bug report (IOT-645) which claims this "build in the source
      dir" behavior inhibits multiple builds of different targets at the same
      time on one machine/instance, although that bug is focused on extlibs
      which is its own story, builds there are only initiated by scons passing
      control to some other builder (make, etc.) so harder to solve.
      Part one of this patch series is fixing resource/csdk/connectivity.
      The main type of thing which causes the issue is:
          src_dir = os.path.abspath(os.curdir)
      This absolute path (which scons has no ability to adjust to use the
      variant dir) is typically joined with source file names in subdirectories
      when the builder will not be invoked in that directory. Replacing that
      model, source files are now added as File objects (instead of simple
      path strings), which leaves scons in full knowlege of the file and how
      to find it. It's possible a plain filename string would be good enough;
      scons is aware of the location it's in when running a given script.
      A challenge was in the resource/csdk/connectivity/src/*adapter build
      scripts: these invoke a target-specific subsidiary script to add source
      files particular to the target (tizen, android, etc.) - but not all
      possible build tergets have a script for each adapter.  So the scripts
      checked for the script using os.path.exists() using an absolute path as
      noted above, as it must since the Python module does not know scons path
      tools, but then when calling it using the same path, the context is wrong
      and the added sources and thus their derived object dependencies were
      relative to the source tree, not the the variant dir. Again using a File
      object, it is possible to extract both a regular (variant-adjustable)
      path and a srcdir-relative path, the latter used for the check by
      With this change, of the original 81 non-extlibs and non-libcoap builds
      not happening in variant dir, there are only four remaining (though note
      counts are build-dependent and this only refers to Linux x86_64 with the
      options I used). Those four will be the subject of part 2/3.  (Part 3/3
      is already merged to master and fixed the ones coming from bridging/):
      Preparing target resource/c_common/oic_malloc/src/oic_malloc.o...
      Preparing target resource/csdk/logger/src/logger.o...
      Preparing target resource/c_common/oic_string/src/oic_string.o...
      Preparing target resource/src/OCRepresentation.o...
      While working on this, a few missed list-assignment reformattings were
      snuck in, these should clearly be seen to be zero-impact.
      Additionally, in a few places when a comparison is done against a list
      which will be used as if it were immutable, like:
          if foo in ['linux', 'tizen']:
      it was actually changed to be immutable, i.e. [] changed to tuple ().
      Some old debugging prints announcing when a script is being scanned were
      also dropped.
      This change is independent of the others in the series.
      Bug: https://jira.iotivity.org/browse/IOT-645
      Change-Id: I54ba8c6613bcfefb6dba64687e9f1a0e72327a41
      Signed-off-by: default avatarMats Wichmann <mats@linux.com>
  17. 19 Sep, 2017 1 commit
  18. 14 Sep, 2017 1 commit
    • saurabh.s9's avatar
      Security error notification engine · ad1f7db6
      saurabh.s9 authored
      Errors happens during OCDoResource calls should be returned to app layer
      Previously, session errors (handshake failed) didn't returned properly to app layer
      and this cause side effects (CA retransmission works in cases when it should not)
      Current state:
      1. Source code builds ok
      2. Secure stack samples (UDP/TCP) works well (both positive/negative cases)
      3. Provisioning (OTM, 20th menu item) works well for following:
         a. justworks    positive UDP/TCP, negative UDP case
         b. mfg          positive UDP/TCP, negative UDP case
         c. mv_justworks positive UDP/TCP, negative UDP case
         d. randompin    positive UDP/TCP, negative UDP case
      4. OTM in provisioning via TCP - negative case - should work properly after fix IOT-2454
      How to test:
      1. Positive case - just test samples (f.e secure stack samples) & provisioning with all servers
      2. Negative case - add following code which artificially breaks handshake (to ca_adapter_net_ssl.c)
         if (peer->ssl.state == MBEDTLS_SSL_CERTIFICATE_REQUEST)
         And again test all samples and provisioning with all servers.
         As result - you should see an error returned to app immidiately (without timeouts, etc)
         and there should be no CA retransmission attempts (UDP case)
      Change-Id: Ia1fe1c7c58f9e40040a0be5e7e83abbc66f80bfe
      Signed-off-by: default avatarAndrii Shtompel <a.shtompel@samsung.com>
      Signed-off-by: default avatarsaurabh.s9 <saurabh.s9@samsung.com>
  19. 29 Aug, 2017 1 commit
  20. 14 Aug, 2017 1 commit
  21. 12 Aug, 2017 1 commit
  22. 27 Jun, 2017 1 commit
  23. 20 Jun, 2017 1 commit
  24. 18 Jun, 2017 1 commit
  25. 17 Jun, 2017 1 commit
  26. 16 Jun, 2017 1 commit
  27. 15 Jun, 2017 1 commit
  28. 14 Jun, 2017 1 commit
  29. 12 Jun, 2017 1 commit
  30. 08 Jun, 2017 1 commit
  31. 24 May, 2017 1 commit
  32. 23 May, 2017 1 commit
  33. 22 May, 2017 1 commit
  34. 19 May, 2017 1 commit
  35. 15 May, 2017 2 commits
  36. 10 May, 2017 1 commit
  37. 02 May, 2017 2 commits
    • Todd Malsbary's avatar
      connectivity: Link unitests to sqlite3 · ea37fc9c
      Todd Malsbary authored
      Problem was observed while building with RD_MODE and gcc-6.3.
      g++ \
      -o out/linux/x86_64/release/resource/csdk/connectivity/test/catests \
      /bin/ld: \
      out/linux/x86_64/release/liboctbstack_internal.a(oicresourcedirectory.o): \
      undefined reference to symbol 'sqlite3_close'
      Change-Id: I6f0a3588cd816fd186db25df92b4b79db0bae6a5
      Signed-off-by: default avatarTodd Malsbary <todd.malsbary@intel.com>
      Reviewed-on: https://gerrit.iotivity.org/gerrit/19379Tested-by: default avatarjenkins-iotivity <jenkins@iotivity.org>
      Reviewed-by: default avatarDan Mihai <Daniel.Mihai@microsoft.com>
    • Dan Mihai's avatar
      [IOT-2014] linker changes for connectivity_abstraction · 385deffa
      Dan Mihai authored
      Windows currently has several different copies of
      connectivity_abstraction code and data in a single process.
      Other platforms are using a single copy of shared library
      connectivity_abstraction, in each process/app.
      It's better to avoid differences across platforms, because
      otherwise changes tested on one platform might not work on
      the other platforms.
      Linker behavior unchanged by this patch:
      1. On non-Windows platforms: IoTivity sample apps, and apps outside
         IoTivity, continue to link with connectivity_abstraction.
      2. On Windows: IoTivity sample apps, and apps outside IoTivity,
         continue to link with octbstack.lib.
      Linker behavior changed by this patch:
      1. On all platforms: IoTivity-internal tests link with the static LIB
      2. On Windows: IoTivity sample apps, and apps outside IoTivity,
         no longer link directly with connectivity_abstraction.lib.
         They obtain access to connectivity_abstraction APIs by linking
         with octbstack.lib.
      3. On Windows: Octbstack.dll links with the static LIB
         connectivity_abstraction_internal, and exports public
         connectivity_abstraction APIs.
      Change-Id: I48667d08d5be48e828800da2807c030753beab16
      Signed-off-by: default avatarDan Mihai <Daniel.Mihai@microsoft.com>
      Reviewed-on: https://gerrit.iotivity.org/gerrit/18981Tested-by: default avatarjenkins-iotivity <jenkins@iotivity.org>