1. 06 Agu, 2018 1 kayıt (commit)
  2. 05 Agu, 2018 1 kayıt (commit)
  3. 04 Agu, 2018 1 kayıt (commit)
  4. 03 Agu, 2018 2 kayıt (commit)
  5. 02 Agu, 2018 1 kayıt (commit)
  6. 01 Agu, 2018 2 kayıt (commit)
  7. 30 Tem, 2018 1 kayıt (commit)
    • Gabor Kelemen's avatar
      Add missing sal/log.hxx headers · bdb0775a
      Gabor Kelemen yazdı
      rtl/string.hxx and rtl/ustring.hxx both unnecessarily #include <sal/log.hxx> (and don't make use of it themselves), but many other files happen to depend on it.
      This is a continuation of commit 6ff2d84a to be able to remove those unneeded includes.
      
      This commit adds missing headers to every file found by:
      grep -FwL sal/log.hxx $(git grep -Elw 'SAL_INFO|SAL_INFO_IF|SAL_WARN|SAL_WARN_IF|SAL_DETAIL_LOG_STREAM|SAL_WHERE|SAL_STREAM|SAL_DEBUG')
      to directories from filter to jvmfwk
      
      Change-Id: I2a73d63f2aaef5f26d7d08957daaa8a30b412ac5
      Reviewed-on: https://gerrit.libreoffice.org/58204
      Tested-by: Jenkins
      Reviewed-by: 's avatarMiklos Vajna <vmiklos@collabora.co.uk>
      bdb0775a
  8. 28 Tem, 2018 1 kayıt (commit)
  9. 27 Tem, 2018 1 kayıt (commit)
  10. 26 Tem, 2018 1 kayıt (commit)
    • Stephan Bergmann's avatar
      filter: avoid -Werror=deprecated-copy (GCC trunk towards GCC 9) · ec32cb36
      Stephan Bergmann yazdı
      ...by explicitly defaulting the copy/move functions (and, where needed in turn,
      also a default ctor) for classes that have a user-declared dtor that does
      nothing other than an implicitly-defined one would do, but needs to be user-
      declared because it is virtual and potentially serves as a key function to
      emit the vtable, or is non-public, etc.; and by removing explicitly user-
      provided functions that do the same as their implicitly-defined counterparts,
      but may prevent implicitly declared copy functions from being defined as non-
      deleted in the future.  (Even if such a user-provided function was declared
      non-inline in an include file, the apparently-used implicitly-defined copy
      functions are already include, so why bother with non-inline functions.)
      
      Change-Id: I20a2c713f0fea62659d44298c1d98dc9b7f2d5aa
      Reviewed-on: https://gerrit.libreoffice.org/58076
      Tested-by: Jenkins
      Reviewed-by: 's avatarStephan Bergmann <sbergman@redhat.com>
      ec32cb36
  11. 25 Tem, 2018 1 kayıt (commit)
  12. 24 Tem, 2018 1 kayıt (commit)
  13. 22 Tem, 2018 2 kayıt (commit)
  14. 21 Tem, 2018 1 kayıt (commit)
  15. 18 Tem, 2018 2 kayıt (commit)
  16. 13 Tem, 2018 1 kayıt (commit)
  17. 11 Tem, 2018 1 kayıt (commit)
  18. 10 Tem, 2018 3 kayıt (commit)
  19. 09 Tem, 2018 1 kayıt (commit)
  20. 06 Tem, 2018 1 kayıt (commit)
  21. 05 Tem, 2018 1 kayıt (commit)
    • Armin Le Grand's avatar
      Only access css::drawing::PointSequence when not empty · f73eeabf
      Armin Le Grand yazdı
      Had to adapt EscherPropertyContainer::GetPolyPolygon due
      to it using conversions from UNO API drawing::PointSequence
      to old tools::polygon, containing unsafe memory accesses.
      It is not useful to fix that, use new tooling instead.
      
      Before correctly testing nCount for zero in b2dpolygontools.cxx
      when you look closely always a point was added - a random
      one due to accessing random memory.
      This is corrected, so in test case for "tdf104115.docx"
      a PolyPolygon with two polys is used, the first being
      empty (had one point due to the error mentioned above).
      When having no points, CreatePolygonProperties in escherex.cxx
      does badly calculate and alloc the pSegmentBuf array used
      to write to doc formats (in the test case - 20 bytes alloced,
      22 written). This did not happen before due to having
      always a point due to the error before - argh!
      Corrected that and hopefully this will work now.
      
      To be on the safe side and to not need to redefine that whole
      CreatePolygonProperties I will turn back that little change
      and better sort-out empty polygons inside GetPolyPolygon
      alrteady. That should bring us back to the original state,
      at the same time avoiding that CreatePolygonProperties has
      to handle empty Polygons at all.
      That stuff urgently needs cleanup - I took a look and thought
      about using std::vector<sal_uInt8> so no wrong alloc or write
      too much could happen, but that nTotalBezPoints needs to be
      pre-calculated because it gets itself written to that
      buffers...
      
      Change-Id: Iefc885928f5bb29bceaf36c2a1555346bb21fd26
      Reviewed-on: https://gerrit.libreoffice.org/56927
      Tested-by: Jenkins
      Reviewed-by: 's avatarArmin Le Grand <Armin.Le.Grand@cib.de>
      f73eeabf
  22. 04 Tem, 2018 1 kayıt (commit)
  23. 02 Tem, 2018 2 kayıt (commit)
  24. 29 Haz, 2018 1 kayıt (commit)
  25. 27 Haz, 2018 1 kayıt (commit)
  26. 22 Haz, 2018 1 kayıt (commit)
  27. 20 Haz, 2018 2 kayıt (commit)
  28. 19 Haz, 2018 1 kayıt (commit)
  29. 18 Haz, 2018 4 kayıt (commit)