A number of methods in main/toolkit/source/layout/vcl/* use either
"!this" or "this" in a boolean context in order to detect being
called with a null object and exit early. In a valid C++ pr

A number of methods in main/toolkit/source/layout/vcl/* use either
"!this" or "this" in a boolean context in order to detect being
called with a null object and exit early. In a valid C++ program
"this" will never be null, so a compiler could legally optimize out
this comparision, which could potentially result in the method
dereferencing a null pointer later in the code. This situation
could only happen if the caller is using a null object pointer to
call the method or is using a object ref to call the method that
was generated by dereferencing a null pointer, neither of which is
valid. Resolve this by moving the checks out of the method and
into the caller.

Make this easier by changing the getImpl() method to return the
private *Impl pointer directly instead of deferencing the pointer
and returning a ref. The latter is invalid if the pointer is null.
This allows GetImpl() to be called in a boolean contect to peform
the check. It also allows a number of instances of "&getImpl()"
calls in a boolean context to be fixed by changing them to "getImpl()".
The address of a ref will never be zero in a valid C++ program, so
the compiler could potentially optimize out those checks.

There does not appear to be any need for Control and ComboBox to
use customized versions of GetImpl() since these appear to behave
identically to the versions generated by the canned macro, so switch
them back to the macro version.

This commit should result in no functional changes.

It seems like all of these checks for a null implementation should
not be necessary, but that requires further investigation.



git-svn-id: https://svn.apache.org/repos/asf/openoffice/trunk@1823225 13f79535-47bb-0310-9956-ffa450edef68

show more ...

Update headers to Alv2 headers

git-svn-id: https://svn.apache.org/repos/asf/incubator/ooo/trunk@1198492 13f79535-47bb-0310-9956-ffa450edef68

Initial import of the old OOo hg repository tip revision.

.../trunk/main is a copy of (currently tip-most)
http://hg.services.openoffice.org/OOO340/rev/c904c1944462

.../trunk/

Initial import of the old OOo hg repository tip revision.

.../trunk/main is a copy of (currently tip-most)
http://hg.services.openoffice.org/OOO340/rev/c904c1944462

.../trunk/extras/l10n is a copy of (currently tip-most)
http://hg.services.openoffice.org/master_l10n/OOO340/rev/af6bc9467af5

Note that the following files with line-end and/or encoding anomalies were left out (they will need to be to be checked in separately):

/ooo/trunk/core/dictionaries/de_DE/README_hyph_de_DE.txt
/ooo/trunk/core/dictionaries/de_CH/README_hyph_de_CH.txt
/ooo/trunk/core/dictionaries/de_AT/README_hyph_de_AT.txt
/ooo/trunk/core/gettext/gettext-0.18.1.1.patch
/ooo/trunk/core/apache-commons/patches/codec.patch
/ooo/trunk/core/libcroco/libcroco-0.6.2.patch
/ooo/trunk/core/testautomation/writer/optional/input/import/mactext.txt
/ooo/trunk/core/graphite/graphite-2.3.1.patch
/ooo/trunk/core/hwpfilter/source/hwpeq.cpp
/ooo/trunk/core/solenv/bin/cwstouched.pl
/ooo/trunk/core/readlicense_oo/html/THIRDPARTYLICENSEREADME.html
/ooo/trunk/core/writerfilter/source/doctok/escher.html
/ooo/trunk/core/writerfilter/source/odiapi/qname/resource/office2003/WordprocessingML Schemas/xsdlib.xsd
/ooo/trunk/core/writerfilter/source/odiapi/qname/resource/office2003/WordprocessingML Schemas/wordnetaux.xsd
/ooo/trunk/core/filter/source/xslt/odf2xhtml/export/common/body.xsl
/ooo/trunk/core/filter/source/xslt/odf2xhtml/export/common/styles/style_mapping_css.xsl

Also: Repository.mk from the l10n toplevel


git-svn-id: https://svn.apache.org/repos/asf/incubator/ooo/trunk@1162288 13f79535-47bb-0310-9956-ffa450edef68

show more ...