office-gobmx/filter
Stephan Bergmann aef7feb3e6 New loplugin:unsignedcompare
"Find explicit casts from signed to unsigned integer in comparison against
unsigned integer, where the cast is presumably used to avoid warnings about
signed vs. unsigned comparisons, and could thus be replaced with
o3tl::make_unsigned for clairty." (compilerplugins/clang/unsignedcompare.cxx)

o3tl::make_unsigned requires its argument to be non-negative, and there is a
chance that some original code like

  static_cast<sal_uInt32>(n) >= c

used the explicit cast to actually force a (potentially negative) value of
sal_Int32 to be interpreted as an unsigned sal_uInt32, rather than using the
cast to avoid a false "signed vs. unsigned comparison" warning in a case where
n is known to be non-negative.  It appears that restricting this plugin to non-
equality comparisons (<, >, <=, >=) and excluding equality comparisons (==, !=)
is a useful heuristic to avoid such false positives.  The only remainging false
positive I found was 0288c8ffec "Rephrase cast
from sal_Int32 to sal_uInt32".

But which of course does not mean that there were no further false positivies
that I missed.  So this commit may accidentally introduce some false hits of the
assert in o3tl::make_unsigned.  At least, it passed a full (Linux ASan+UBSan
--enable-dbgutil) `make check && make screenshot`.

It is by design that o3tl::make_unsigned only accepts signed integer parameter
types (and is not defined as a nop for unsigned ones), to avoid unnecessary uses
which would in general be suspicious.  But the STATIC_ARRAY_SELECT macro in
include/oox/helper/helper.hxx is used with both signed and unsigned types, so
needs a little oox::detail::make_unsigned helper function for now.  (The
ultimate fix being to get rid of the macro in the first place.)

Change-Id: Ia4adc9f44c70ad1dfd608784cac39ee922c32175
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87556
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-01-28 07:42:15 +01:00
..
inc
qa
source New loplugin:unsignedcompare 2020-01-28 07:42:15 +01:00
uiconfig/ui Revert "lok: ui: more files to increase the 'step-increment'" 2020-01-24 12:40:55 +01:00
AllLangMoTarget_flt.mk
Configuration_filter.mk
CppunitTest_filter_dialogs_test.mk
CppunitTest_filter_dxf_test.mk
CppunitTest_filter_eps_test.mk
CppunitTest_filter_met_test.mk
CppunitTest_filter_msfilter.mk
CppunitTest_filter_pcd_test.mk
CppunitTest_filter_pcx_test.mk
CppunitTest_filter_pict_test.mk
CppunitTest_filter_ppm_test.mk
CppunitTest_filter_priority.mk
CppunitTest_filter_psd_test.mk
CppunitTest_filter_ras_test.mk
CppunitTest_filter_textfilterdetect.mk
CppunitTest_filter_tga_test.mk
CppunitTest_filter_tiff_test.mk
CppunitTest_filter_xslt.mk
CustomTarget_svg.mk
IwyuFilter_filter.yaml
JunitTest_filter_complex.mk
Library_filterconfig.mk
Library_flash.mk
Library_gie.mk
Library_graphicfilter.mk
Library_icg.mk
Library_msfilter.mk
Library_odfflatxml.mk
Library_pdffilter.mk tdf#45636 trigger accessibility check when exporting as PDF/UA 2020-01-09 17:05:05 +01:00
Library_storagefd.mk
Library_svgfilter.mk
Library_t602filter.mk
Library_textfd.mk
Library_xmlfa.mk
Library_xmlfd.mk
Library_xsltdlg.mk
Library_xsltfilter.mk
Makefile
Module_filter.mk
Package_docbook.mk
Package_xhtml.mk
Package_xslt.mk
README
UIConfig_filter.mk

Filter registration and some simple filters (also descriptions).

Desperate splitting of code into small shared libraries for historical
reasons presumably (OS/2 and Windows 3.x). The libraries produced from
the code in each subdirectory of filter/source/graphicfilter are
graphic format import or export filters. But they don't have uniform
API. Some have either a GraphicImport or GraphicExport entry point,
and are loaded and used in a uniform fashion from code in
svtools/source/filter/filter.cxx. Others have different API and are
loaded from other places. For instance "icgm" has ImportCGM, and is
loaded and used by sd/source/filter/cgm/sdcgmfilter.cxx (!).
Svgreader is used for "File->Open" and then to choose the svg file.
For "Insert->Picture->From File", see svgio/source/svgreader directory.

====================
filter configuration
====================

The filter configuration consists of two parts, the type definition in
filter/source/config/fragments/types/ and the actual filter definition
in filter/source/config/fragments/filters/.

Each file type e.g. text file should be represented by exactly one
type definition. This type can then be referenced by several different
filters, e.g. calc text, writer text.