sax/source/fastparser/fastparser.cxx | 2 +-
vcl/README.lifecycle | 2 +-
vcl/source/filter/jpeg/transupp.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
New commits:
commit 4550b35781c6d9407da29f64f9b02b9201bf953b
Author: Andrea Gelmini <andrea.gelm...@gelma.net>
AuthorDate: Thu Mar 18 17:15:58 2021 +0100
Commit: Andrea Gelmini <andrea.gelm...@gelma.net>
CommitDate: Fri Mar 19 07:53:41 2021 +0100
Fix typo
Change-Id: Icc75dc0f0d7434233b83fb72aadb4832ea47493e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112694
Reviewed-by: Julien Nabet <serval2...@yahoo.fr>
Tested-by: Jenkins
diff --git a/sax/source/fastparser/fastparser.cxx
b/sax/source/fastparser/fastparser.cxx
index f35e56e8ab7f..8cec8284abce 100644
--- a/sax/source/fastparser/fastparser.cxx
+++ b/sax/source/fastparser/fastparser.cxx
@@ -467,7 +467,7 @@ void Entity::startElement( Event const *pEvent )
if( xContext.is() )
xContext->startFastElement( nElementToken, xAttr );
}
- // swap the reference we own in to avoid referencing thrash.
+ // swap the reference we own in to avoid referencing trash.
maContextStack.top().mxContext = std::move( xContext );
}
catch (...)
diff --git a/vcl/README.lifecycle b/vcl/README.lifecycle
index a309b65ef9ea..0c44fb6a14d8 100644
--- a/vcl/README.lifecycle
+++ b/vcl/README.lifecycle
@@ -42,7 +42,7 @@ to lingering pointers to freed objects.
To fix this situation we now have a VclPtr - which is a smart
reference-counting pointer (include/vcl/vclptr.hxx) which is
designed to look and behave -very- much like a normal pointer
- to reduce code-thrash. VclPtr is used to wrap all OutputDevice
+ to reduce code-trash. VclPtr is used to wrap all OutputDevice
derived classes thus:
VclPtr<Dialog> pDialog( new Dialog( ... ), SAL_NO_ACQUIRE );
diff --git a/vcl/source/filter/jpeg/transupp.c
b/vcl/source/filter/jpeg/transupp.c
index d26cb9510009..318b28d790c1 100644
--- a/vcl/source/filter/jpeg/transupp.c
+++ b/vcl/source/filter/jpeg/transupp.c
@@ -60,7 +60,7 @@ jdiv_round_up (long a, long b)
* arrays are always written in normal scan order (top to bottom) because
* the virtual array manager expects this. The source arrays will be scanned
* in the corresponding order, which means multiple passes through the source
- * arrays for most of the transforms. That could result in much thrashing
+ * arrays for most of the transforms. That could result in much trashing
* if the image is larger than main memory.
*
* If cropping or trimming is involved, the destination arrays may be smaller
_______________________________________________
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
