| #
914d351e
|
| 16-Jul-2025 |
John Bampton <jbampton@users.noreply.github.com> |
pre-commit auto clean trailing whitespace in dxp and hxx files (#381)
A huge auto clean up by pre-commit and I can make smaller PRs if needed.
Seems we have a lot of extra whitespace junk in our co
pre-commit auto clean trailing whitespace in dxp and hxx files (#381)
A huge auto clean up by pre-commit and I can make smaller PRs if needed.
Seems we have a lot of extra whitespace junk in our code base
The NeverEnding Story was a great film back in the old days :)
Great video and theme song by Limahl
https://www.youtube.com/watch?v=lHytjEj7B9g
https://en.wikipedia.org/wiki/The_NeverEnding_Story_(film)
show more ...
|
| #
5e0f18e3
|
| 05-Feb-2018 |
Don Lewis <truckman@apache.org> |
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
"t
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 ...
|