[Libreoffice-commits] core.git: sax/source vcl/README.lifecycle vcl/source

[Andrea Gelmini (via logerrit)]

 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.gelmini at gelma.net>
AuthorDate: Thu Mar 18 17:15:58 2021 +0100
Commit:     Andrea Gelmini <andrea.gelmini at 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 <serval2412 at 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