summaryrefslogtreecommitdiff
path: root/include/sal
AgeCommit message (Collapse)Author
2015-05-04sal: match the defintions of SAL_MAX_SIZE and sal_SizeMichael Stahl
With 64-bit MSVC, sizeof(long) is 4 but sizeof(void*) is 8, so this would select sal_uInt64 but SAL_MAX_UINT32. This should make sizeof(sal_Size) the same as sizeof(size_t) on all supported platforms, but still sal_Size maps to different integer type (long vs. int) than size_t on 32-bit. Change-Id: I638aac6b502e624ed6b01f5921e20bc40f42480c
2015-04-29dbaccess: log exception messages in ORowSetCacheMichael Stahl
Change-Id: I1c76d4ce91d1f22d88106918ab139b17f6f017f0
2015-04-10Update @since tags LO 4.5 -> 5.0Stephan Bergmann
Change-Id: Idb2e46fcaa080d6763d2e3ed963f7673a2353eb2
2015-03-19We require MSVC2013 (_MSC_VER == 1800) nowTor Lillqvist
Change-Id: Ice8504041f22e00f2e5010813d9dff1d2987c8d6
2015-03-18'#if defined(SAL_W32) || defined(SAL_UNX)' matches all our platforms.Tor Lillqvist
Change-Id: I6b46eea0890573166d8a49e8060716907f223a1d
2015-03-14tdf#43157: Enable format check in sal_detail_logFormatStephan Bergmann
Change-Id: I65296dd9b4b13fc1c3a3d8eed738e257b204b691
2015-03-13tdf#43157: Fix format string violations in OSL_TRACE etc.Stephan Bergmann
...for a 32-bit build, similar to what ee11e221d2108212619e1bbe7f029e7d9afdba32 "tdf#43157: Fix format string violations in OSL_TRACE etc." did for a 64-bit build Change-Id: I05dd79ede3e66cb9ab7a33792319eb34b34c82dd
2015-02-23file UCP: Ensure myLocalTime is initializedStephan Bergmann
When a file's time is epoch (1970-01-01 00:00:00, i.e., TimeValue temp is all zero) and the TZ is UTC or westward, osl_getLocalTimeFromSystemTime returns false and leaves myLocalTime uninitialized. That e.g. confuses getModuleByUrl (scripting/source/pyprov/pythonscript.py), potentially re-loading a Python script with epoch time (as happens e.g. for the share/Scripts/python/ files in an xdg-app installation of LO) every time it is accessed, falsely assuming it has changed on disk since last load. Change-Id: I8d4228feb28e2697a7021e3488ae2c09e8439ed8
2015-02-17tdf#88428: Add GUI to select one of user-configured Time Stamp AuthoritiesTor Lillqvist
Work in progress. The selection not used for anything yet. Change-Id: Ia86fa0f59dcfee8e9d332a028a3fad37f4019fe0
2015-02-13Ah, Clang has some "type_visiblity" well-kept secretStephan Bergmann
"[...] to allow users to control the visibility of a type for the purposes of RTTI [...]" (<http://llvm.org/viewvc/llvm-project?view=revision&revision=175587>), so fits well for SAL_DLLPUBLIC_RTTI Change-Id: I6494e027c3af176591ffeb1d6a8965b7d40db1a9
2015-02-12Make CppunitTest_services instantiate even more servicesStephan Bergmann
Change-Id: Id9bfb3886e4a9cbc15a7bf7ef3aefa73bd160e3b
2015-02-12Remove uses of osl/diagnose.h from jvmaccessStephan Bergmann
Change-Id: Ic9cda5259db81dd921dd3fa891b1289b8283bf27
2015-02-11comphelper: add SAL_INFO for exception when graphic cannot be loadedMichael Stahl
Change-Id: Ia0a4834987ae040a31e19276ece20b74b59ca445
2015-02-09log-areas.dox: clean up oox messMichael Stahl
Change-Id: Ib1ec1ae009115dcc8f50ca3038bc9a35b7cb09a9
2015-02-06Make OUStringLiteral more usefulStephan Bergmann
...don't dare make it non-explicit, yet. Along the way, introduce SAL_CONSTEXPR. Change-Id: Ia3179d0d5e001fd7aa92237c97437e9b74366ee1
2015-02-03add some SAL_INFO to group area listener and formula cell ctor/dtorEike Rathke
guess we'll need them more often.. Change-Id: I0ef149fc5edceee765419764bf0efa571ba9d977
2015-01-29cppu: the LogBrige really needs its own SAL_LOG areaMichael Stahl
Change-Id: I129f3dc1597035664e4ff284276cb0d49a560ab5
2015-01-22Revert "fdo#88475 BrowseBox/grid: reposition data cursor to current row ↵Lionel Elie Mamane
after paint" (and its later fixup) This reverts commits e8a68c1f50f32a0f9d8bcdf16c1270c319910baa e60b589952985edff12b1a28392ce6fa0ca8d9be It was a work-around for the real underlying issue, which was that the result of dbaccess::ResultSet::isFirst() et al were clobbered by moves made by its clones. The BrowseBox has two different cursors: 1) One for data to edit (which is kept on the current/active row) 2) One for data to *paint* The second is a clone of the first. The real underlying issue is fixed by: commit d7c9a1d9d65fe8b1a56c5c280d2ca6640a549d2f Author: Lionel Elie Mamane <lionel@mamane.lu> Date: Thu Jan 22 10:49:42 2015 +0100 fdo#88475 RowSetBase: reposition cache before interrogating it Change-Id: I28d62673fdf10ee6507d38bb7c79c08e4b40902f
2015-01-22SAL_DLLPUBLIC_RTTI for proper RTTI visibility for LLVMStephan Bergmann
The Itanium C++ ABI mandates that for a unique (complete) C++ type a single unique symbol for the type's RTTI name is used across a process's dynamic objects (so type equivalence can be determined via pointer comparison on the RTTI names). GCC nowadays deviates from that, using strcmp to determine equivalence, so it is resilient to RTTI names being bound locally within dynamic objects (which has performance benefits, but also makes it impossible to have unrelated types that happen to have the same name "encapsulated" in individual dynamic objects--- whether or not that would violate the ODR would be open to interpretation of how dynamic objects fit into the C++ Standard). LLVM sticks to the Itanium ABI, which becomes notable in at least two places: For one, libc++abi's __dynamic_cast uses strict checking. It still has a _LIBCXX_DYNAMIC_FALLBACK for now that additionally uses strcmp checking and syslogs visibility violations. Mac OS X uses libc++abi with _LIBCXX_DYNAMIC_FALLBACK enabled, and running LO routinely logs dynamic_cast errors to the Console there. For another, RTTI-based UBSan checks unconditionally only use strict checking (cf. isDerivedFromAtOffset in lib/ubsan/ubsan_type_hash.cc). This causes false positives from Clang -fsanitize=function and -fsanitize=vptr even on Linux not using libc++abi. Therefore, introduce SAL_DLLPUBLIC_RTTI to mark types for which RTTI needs to have default visibility under the Itanium/LLVM semantics. There is unfortunately no way to mark only the (implicitly generated) RTTI symbols for default visibility, but at least with the cases where SAL_DLLPUBLIC_RTTI is used for now that is no real problem---any class type marked SAL_DLLPUBLIC_RTTI only has inline (covered by -fvisibility-inlines-hidden) or undefined pure virtual functions. It appears that even the vtables of those classes remain hidden, at least with Mach-O on Mac OS X. (That also means there is no need for a SAL_DLLPRIVATE_RTTI marker analoguous to the---also superfluous in retrospect--- CPPU_GCC_DLLPRIVATE one.) Nevertheless, the number of exported symbols of course increases when SAL_DLLPUBLIC_RTTI is "active." For a full-blown --enable-dbgutil build on Mac OS X, find instdir/LibreOffice.app/Contents -name \*.dylib\* -exec nm -gU {} \; \ wc -l increased from 125541 to 139239. For Linux, an option might be to "activate" SAL_DLLPUBLIC_RTTI only for __clang__ plus !ENABLE_RUNTIME_OPTIMIZATIONS. The set of types marked SAL_DLLPUBLIC_RTTI with this patch (wholesale cppumaker- generated UNO enum, struct, and interface types; plus some IEmbeddedHelper and IUndoManager) is chosen so that a full "make check" on Mac OS X no longer syslogs any dynamic_cast errors to the Console. Change-Id: I42fa6ec01c2503ec24bcd9c0518abb112afa3235
2015-01-19fixup previous commit:Lionel Elie Mamane
OSL_ENSURE does not execute in non-debug builds (and is deprecated). Do not try to seek back if paint did not seek. This happens in particular when there is no data source attached (and thus trying to seek fails). Change-Id: I3f4908c4dcae2bb120bf58c1218e3386c40d5721
2015-01-17sal: multiple use of section label 'svl'Miklos Vajna
Change-Id: Ia6c178dd9390bf75a08c0d53e6505582a7f5ab4f
2015-01-17Leave a comment about the lesson learnedTakeshi Abe
from 234e45bf1d27484b72e73fe327b1e92fda1933f1 Change-Id: Ic1bcab8a9662e2f302a24a6eaad2f813c12b28a8
2015-01-16Revert "never wonder if sun is not sun"Stephan Bergmann
This reverts commit 06a5b619a76c96783ee67bdcfd21f203d3ddb53c, which broke Solaris/Illumos builds for no good reason, cf. mail thread starting at <http://lists.freedesktop.org/archives/libreoffice/2015-January/065844.html> "4.4.0.1 build error on sal/types.h on solaris/illumos." Conflicts: include/sal/config.h Change-Id: I063453ee1115ae3f97e2835828800c74e3cb5e48
2015-01-07Silence unhelpful -Wpotentially-evaluated-expressionStephan Bergmann
...on Clang trunk towards 3.6, firing for typeid(*e) where e is a side-effecting expression (of polymorphic pointer type). Simpler to disable it via #if in sal/config.h than to disable it in solenv/gbuild/platform/com_GCC_defs.mk with an additional feature test in configure.ac. Change-Id: If94692a9e06ff2659bf168b4968200aeee9ebb0a
2014-12-18The touch module, ByteBufferWrapper, and the libotouch library can go away nowTor Lillqvist
Change-Id: I6f4a6679c263ac81d1cf5c66f18782e857da5ff8
2014-11-24svl: convert DBG_ASSERTs in SfxItemSetMichael Stahl
Change-Id: I37e507226e676ee797e6911a0b3da1d1823e750a
2014-11-10never wonder if sun is not sunTakeshi Abe
By the way an item of the following page suggests the same snipet: <http://www.faqs.org/faqs/ui-builders/TeleUSE/> while I am not sure if it was the case. Change-Id: I9fb0ea0e872cb1697aa953a406527472f0cbccde Reviewed-on: https://gerrit.libreoffice.org/12330 Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com> Tested-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
2014-10-29tools: remove DBG_ERRORFILE and replace all callersMichael Stahl
Change-Id: Ic76ccc49b9291fe82c56974eb6237cd3b85d91c8
2014-10-02remove HAVE_GCC_PRAGMA_DIAGNOSTIC_SCOPE check and macroMichael Stahl
This is supported in GCC 4.6.0 already: https://gcc.gnu.org/onlinedocs/gcc-4.6.0/gcc/Diagnostic-Pragmas.html Change-Id: I2f67e588eea3a323a2e9c81e39e56ab2e715a817
2014-10-02remove HAVE_GCC_PRAGMA_DIAGNOSTIC_MODIFY check and macroMichael Stahl
This has been supported by GCC and clang for a very long time. Change-Id: I410a2b39004c932003f8cbefe935aedb109b1163
2014-09-17Improve loggingStephan Bergmann
Change-Id: I9c879cc16de0d5353a5ab8ce4c8a8cd7f000a170
2014-09-10WaE: unknown log areaTor Lillqvist
Change-Id: I3339324ec99bbed56f81f2aa4e6cf54edcbec8e6
2014-08-26sw HTML export: don't crash on embedded object without native dataMiklos Vajna
Change-Id: I26fa823b987b2edfbb1be054a5f4d03bbe95a308
2014-08-22add formula.uiEike Rathke
Change-Id: I0e2b38ab8e7fae483539e02e93d25d2532bd70ef
2014-08-14WaE: C4722: destructor never returns, potential memory leakTor Lillqvist
Change-Id: I9691048ca7dc6e18cc904b29e8f6f59b11e002cf
2014-07-16bnc#862510: Improve handling of OOXML gradientsTor Lillqvist
OOXML gradients can have an arbitrary number of "stops". LibreOffice gradients have just a start and end colour, plus an optional uniformly coloured border (on the "start" side). In addition, LibreOffice has the "axial" gradient mode, which means the gradient is reflected in the middle. It is thus obviously impossible in general to losslessly map OOXML gradients to LibreOffice ones. But let's try a bit harder than earlier to get visually more similar result, in at least some simple sample cases. We look for the widest gradient segment and use that for the start and end colours of the LibreOffice gradient. Also, map an OOXML gradient to an axial LibreOffice gradient only if it is symmetrical. Also, use the border property when suitable. In general, look for the widest OOXML gradient segment (once a segment corresponding to the LibreOffice gradient border, if any, has been accounted for) and use that as the LibreOffice gradient. Possibly some perceptionally better heuristic should be used... Like, if we have a three-segment gradient, with a wide gradient segment between two visually very similar colours (for example, two shades of red), and a narrower segment ending with a visually very different colour (for example, yellow), it probably would be best to represent that in LibreOffice as a gradient from the first red shade to yellow, instead of as a gradient between the two shades of red. Or even, if a first or last gradient segment is between very similar colours, equalize those start and end colours, thus using a border colour in LibreOffice instead. The possibilities for bikeshedding are endless. I am sure there are instances where the old code (by accident?) produced visually more pleasing results... But hopefully this works more pleasingly and consistently in a larger number of cases. Change-Id: If153e986ad943454307e3ba718479d5ac4cdc7ab
2014-07-12Add LOK and tiledrendering log areas.Andrzej Hunt
Change-Id: I885acc9b4a52835fa256c2ecd1b8da917b4f7ba7
2014-06-30It is useful to know what macros are we expanding, and to what.Jan Holesovsky
Change-Id: If7704edc5baa9759abc680b8d2040b9cdfe92317
2014-06-25loplugin:sallogareasMiklos Vajna
Change-Id: Ia5fbdfd83971ac946de6d022be55d5a286a1bf5a
2014-06-17-Wstrict-prototypesStephan Bergmann
...no reason to not have it enabled for URE C include files and what little real C code is still left. (But note that Clang ignores that warning.) Change-Id: Ia6940f9f940a0c226e9b724331d65c9862ce32e6
2014-06-10pct import: Add logging.Jan Holesovsky
Change-Id: Ia3fe1ff0075434d0b6903bf978c16499e07d699d
2014-06-05remove the definition of SAL_THROW macroNoel Grandin
Change-Id: I3d389174684cdc86ddb098629da57ebf142424c9
2014-05-23Add SAL_INFO tracing for CoreText callsTor Lillqvist
Change-Id: Ie60e0b64a2d9d8a045cb3c59fc781d6f9b2808a0
2014-05-22Avoid undef use of null ptr, use offsetof insteadStephan Bergmann
Change-Id: I095f45b537690fe98bf385d99194db6319d7ac93
2014-05-22WaE: unused variable 'bHandled'Tor Lillqvist
While at it, make it use SAL_INFO instead of fprintf. Change-Id: Id4018819f8f790bef219e5aca3b6bbb5f6acd6aa
2014-05-21Use more specific tagTor Lillqvist
Change-Id: Ife10cae3f0bd7dd294c74799412528f2596369c8
2014-05-18fix include guard for sal/types.hThomas Arnhold
Change-Id: I77e10d2644b18b150f9489c7f754405974af107a
2014-05-15loplugin:sallogareasStephan Bergmann
Change-Id: Ic3e2a5ed247b35b4e6d80a4ad824bc9b535783fb
2014-05-15Add connectivity.odbcTor Lillqvist
Change-Id: I2bad7938ddd02da8aa7191aebbd9221220fb303e
2014-05-13More warnings related to glTF renderingZolnai Tamás
Use avmedia.opengl to be more explicit. Change-Id: I07878c3648de2e4786bf8a5144ef0c1fbb5530f1
generated by cgit (git 2.34.1) at 2025-01-22 18:37:32 +0000