Age | Commit message (Collapse) | Author | Files | Lines |
|
Convert char to unsigned char first in some found use cases.
In these cases the chart is converted to an unsigned integer,
so characters with negativ values would be converted to wierd
values around the maximum value of sal_uInt32.
Change-Id: I5570b414ff9c0178222ec40830b490824d8abb07
Reviewed-on: https://gerrit.libreoffice.org/84690
Tested-by: Jenkins
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
|
|
The caughed code is actually unused, so remove it.
Change-Id: I82c21cef7e125087f167ccb571a9f8efe1aa548c
Reviewed-on: https://gerrit.libreoffice.org/84689
Tested-by: Jenkins
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
|
|
which merely announce that the next declaration is a class
Change-Id: Ifdb1398bcd99816b13e0b3769b46d0562bfbc1dc
Reviewed-on: https://gerrit.libreoffice.org/84229
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...following up on 314f15bff08b76bf96acf99141776ef64d2f1355 "Extend
loplugin:external to warn about enums".
Cases where free functions were moved into an unnamed namespace along with a
class, to not break ADL, are in:
filter/source/svg/svgexport.cxx
sc/source/filter/excel/xelink.cxx
sc/source/filter/excel/xilink.cxx
svx/source/sdr/contact/viewobjectcontactofunocontrol.cxx
All other free functions mentioning moved classes appear to be harmless and not
give rise to (silent, even) ADL breakage. (One remaining TODO in
compilerplugins/clang/external.cxx is that derived classes are not covered by
computeAffectedTypes, even though they could also be affected by ADL-breakage---
but don't seem to be in any acutal case across the code base.)
For friend declarations using elaborate type specifiers, like
class C1 {};
class C2 { friend class C1; };
* If C2 (but not C1) is moved into an unnamed namespace, the friend declaration
must be changed to not use an elaborate type specifier (i.e., "friend C1;"; see
C++17 [namespace.memdef]/3: "If the name in a friend declaration is neither
qualified nor a template-id and the declaration is a function or an
elaborated-type-specifier, the lookup to determine whether the entity has been
previously declared shall not consider any scopes outside the innermost
enclosing namespace.")
* If C1 (but not C2) is moved into an unnamed namespace, the friend declaration
must be changed too, see <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71882>
"elaborated-type-specifier friend not looked up in unnamed namespace".
Apart from that, to keep changes simple and mostly mechanical (which should help
avoid regressions), out-of-line definitions of class members have been left in
the enclosing (named) namespace. But explicit specializations of class
templates had to be moved into the unnamed namespace to appease
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92598> "explicit specialization of
template from unnamed namespace using unqualified-id in enclosing namespace".
Also, accompanying declarations (of e.g. typedefs or static variables) that
could arguably be moved into the unnamed namespace too have been left alone.
And in some cases, mention of affected types in blacklists in other loplugins
needed to be adapted.
And sc/qa/unit/mark_test.cxx uses a hack of including other .cxx, one of which
is sc/source/core/data/segmenttree.cxx where e.g. ScFlatUInt16SegmentsImpl is
not moved into an unnamed namespace (because it is declared in
sc/inc/segmenttree.hxx), but its base ScFlatSegmentsImpl is. GCC warns about
such combinations with enabled-by-default -Wsubobject-linkage, but "The compiler
doesn’t give this warning for types defined in the main .C file, as those are
unlikely to have multiple definitions."
(<https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Warning-Options.html>) The
warned-about classes also don't have multiple definitions in the given test, so
disable the warning when including the .cxx.
Change-Id: Ib694094c0d8168be68f8fe90dfd0acbb66a3f1e4
Reviewed-on: https://gerrit.libreoffice.org/83239
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
see bt:
0 0x00007ffff209866a in std::type_info::name() const (this=0x0) at /usr/include/c++/9/typeinfo:100
1 0x00007ffff20966e1 in exceptionToStringImpl(rtl::OStringBuffer&, com::sun::star::uno::Any const&)
(sMessage="DBG_UNHANDLED_EXCEPTION in bool connectivity::hsqldb::OHsqlConnection::impl_isTextTable_nothrow(const rtl::OUString&) exception: com.sun.star.sdbc.SQLException message: Unexpected token: S in statemen"..., caught=
uno::Any("com.sun.star.sdbc.SQLException": {<com::sun::star::uno::Exception> = {Message = "Unexpected token: S in statement [s]", Context = uno::Reference to (com::sun::star::uno::XInterface *) 0x555559269238}, SQLState = "37000", ErrorCode = -11, NextException = uno::Any(void)})) at /home/julien/lo/libreoffice/tools/source/debug/debug.cxx:113
2 0x00007ffff209855d in DbgUnhandledException(com::sun::star::uno::Any const&, char const*, char const*, char const*, char const*) (caught=
uno::Any("com.sun.star.sdbc.SQLException": {<com::sun::star::uno::Exception> = {Message = "Unexpected token: S in statement [s]", Context = uno::Reference to (com::sun::star::uno::XInterface *) 0x555559269238}, SQLState = "37000", ErrorCode = -11, NextException = uno::Any(void)}), currentFunction=0x7fffdb5ca340 "bool connectivity::hsqldb::OHsqlConnection::impl_isTextTable_nothrow(const rtl::OUString&)", fileAndLineNo=0x7fffdb5ca2e8 "/home/julien/lo/libreoffice/connectivity/source/drivers/hsqldb/HConnection.cxx:301: ", area=0x7fffdb5c9f49 "connectivity.hsqldb", explanatory=0x0)
at /home/julien/lo/libreoffice/tools/source/debug/debug.cxx:418
3 0x00007fffdb58a16a in connectivity::hsqldb::OHsqlConnection::impl_isTextTable_nothrow(rtl::OUString const&) (this=0x555558a43de0, _rTableName="William Kidwell's Address Book")
at /home/julien/lo/libreoffice/connectivity/source/drivers/hsqldb/HConnection.cxx:301
https://bugs.documentfoundation.org/attachment.cgi?id=155952
Change-Id: I2bc744164b1470d8f09bcb126b02e48af180e886
Reviewed-on: https://gerrit.libreoffice.org/83245
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
This will compile test with maximal supported instruction set
supported by the compiler, but the CPU might not support the
instructions sets. As this tests some aspects of runtime CPU
detection only we actually don't need to compile it with the
INTRINSICS_CXXFLAGS flags.
Change-Id: I612785949b42efbd08d1961a746025f66e99aebc
Reviewed-on: https://gerrit.libreoffice.org/82422
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
I started with 32 and kept doubling the size until the site
did not need re-alloc, but clamped it at 512.
Change-Id: I55fe36b31cd3d40f86e5729337a927cf920f2af6
Reviewed-on: https://gerrit.libreoffice.org/81960
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
I started with 32 and kept doubling the size until the site
did not need re-alloc, but clamped it at 512 (e.g. in emfio/).
Change-Id: Ib7caf35a1b7e42b0e4ed8aa812493449e3eefc8f
Reviewed-on: https://gerrit.libreoffice.org/81540
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I385587a922c555c320a45dcc6d644315b72510e9
Reviewed-on: https://gerrit.libreoffice.org/81278
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...(new with Clang 10 trunk), as seen during CppunitTest_emfio_wmf:
> tools/source/stream/stream.cxx:808:32: runtime error: applying non-zero offset 10 to null pointer
> #0 in SvStream::SeekRel(long) at tools/source/stream/stream.cxx:808:32
> #1 in (anonymous namespace)::ImplReadDIBFileHeader(SvStream&, unsigned long&) at vcl/source/gdi/dibtools.cxx:1085:19
> #2 in (anonymous namespace)::ImplReadDIB(Bitmap&, AlphaMask*, SvStream&, bool, bool, bool) at vcl/source/gdi/dibtools.cxx:1656:12
> #3 in ReadDIB(Bitmap&, SvStream&, bool, bool) at vcl/source/gdi/dibtools.cxx:1738:12
> #4 in emfio::EmfReader::ReadEnhWMF() at emfio/source/reader/emfreader.cxx:1507:33
> #5 in emfio::emfreader::XEmfParser::getDecomposition(com::sun::star::uno::Reference<com::sun::star::io::XInputStream> const&, rtl::OUString const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) at emfio/source/emfuno/xemfparser.cxx:148:72
> #6 in non-virtual thunk to emfio::emfreader::XEmfParser::getDecomposition(com::sun::star::uno::Reference<com::sun::star::io::XInputStream> const&, rtl::OUString const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) at emfio/source/emfuno/xemfparser.cxx
> #7 in VectorGraphicData::ensureSequenceAndRange() at vcl/source/gdi/vectorgraphicdata.cxx:172:137
> #8 in VectorGraphicData::getPrimitive2DSequence() const at vcl/source/gdi/vectorgraphicdata.cxx:279:45
> #9 in ImpGraphic::ImplGetGDIMetaFile() const at vcl/source/gdi/impgraph.cxx:844:110
> #10 in Graphic::GetGDIMetaFile() const at vcl/source/gdi/graph.cxx:365:26
> #11 in ReadWindowMetafile(SvStream&, GDIMetaFile&) at vcl/source/filter/wmf/wmf.cxx:62:25
> #12 in WmfTest::testEmfProblem() at emfio/qa/cppunit/wmf/wmfimporttest.cxx:116:5
An invariant of SvStream appears to be that m_pRWBuf can be null and that
m_pBufPos is null iff m_pRWBuf is null. So don't update m_pBufPos here when
m_pRWBuf is null. (And assert the assumed invariant.)
Change-Id: Iad2eb2723394f5564d43dfa8a3a1a8b8de79158d
Reviewed-on: https://gerrit.libreoffice.org/81237
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
found by the simple expidient of putting asserts in
the resize routine. Where an explicit const size is used,
I started with 32 and kept doubling until that site
did not need resizing anymore.
Change-Id: I998787edc940d0a3ba23b5ac37131ab9ecd300f4
Reviewed-on: https://gerrit.libreoffice.org/81138
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
E.g. #ifdef LIBO_INTERNAL_ONLY is always true for code that builds
with our PCHs.
Change-Id: I3cf311ea3621b909105754cfea2cb0116b8b67f5
Reviewed-on: https://gerrit.libreoffice.org/80961
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Replace them with default initialization or calloc
Change-Id: I747f53c2ced2d0473fd5a5ede4f8520a0633dcc1
Reviewed-on: https://gerrit.libreoffice.org/80805
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
and extend O*StringView to have a constructor that takes a pointer and a
length
Change-Id: I6120e96280f030757e855a6596efdae438b7e1e8
Reviewed-on: https://gerrit.libreoffice.org/80872
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I31c0d004d717564063c36862f9eef661d18768a9
Reviewed-on: https://gerrit.libreoffice.org/80648
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ia0ac30fc8441f446977270c96dd2430647dfa2d7
Reviewed-on: https://gerrit.libreoffice.org/80647
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
and improve the WriteOString method, we can avoid the strlen here, we
already have the length
One change in behaviour to be noted - if the string contains
trailing zero bytes, which ARE INCLUDED IN THE STRING LENGTH,
i.e. I'm not talking about the normal terminating zero, then this
patch changes behaviour because we will now write those zeros to
the stream.
Change-Id: I4668b9b9eb877f820b1dc70d6cd10ba2623bc0a2
Reviewed-on: https://gerrit.libreoffice.org/80597
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
... of the stream in SvStream::SetStreamSize(); this caused
SvMemoryStream with SetStreamSize(0) and subsequent write to be
pre-filled with 0 bytes.
Change-Id: I0de704b319f5087bc6c1914881e38018212afbf2
Reviewed-on: https://gerrit.libreoffice.org/80478
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
Change-Id: I12517651fb3f777fd08e384992bb3e84b340ad85
Reviewed-on: https://gerrit.libreoffice.org/80382
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
deploy a workaround, bug logged against boost as:
https://github.com/boostorg/boost/issues/335
Change-Id: I9791133e926dd474ddc5960a33fd90592ce3dcb3
Reviewed-on: https://gerrit.libreoffice.org/80304
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
E.g. gb_LinkTarget_add_exception_object adds it explicitly, but
gb_LinkTarget_add_cxxobject itself does not, even though other variants
(c,objc,objcxx) do it.
This means that when compiling tools/qa/cppunit/test_cpuid.cxx it
doesn't get the correct -O/-g flags, because CppunitTest_tools_test.mk
uses gb_CppunitTest_add_cxxobjects to add $(INTRINSICS_CXXFLAGS).
And that in its own actually should use the add_exception_objects variant,
it didn't presumably because that one used to have cxxflags passing broken
until I fixed it in 4bbdab901eb3c7d32d28910fb830f4b0422eee91. The usage
in Library_cpp_uno.mk even explicitly works around the lack of debug symbols.
Change-Id: Idc794e95bb817cd2ba2942b8e1f04f80d6722f97
Reviewed-on: https://gerrit.libreoffice.org/80119
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: I441a5ccef6adc8be8029178e304ff3044e812e2a
Reviewed-on: https://gerrit.libreoffice.org/79986
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Iae489fc31b13b836e1df5327ba2fa07e0325907a
Reviewed-on: https://gerrit.libreoffice.org/79793
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
When I did the fast string concatenation, I didn't add any support
for number(), which simply returned a O(U)String, and so it did
the extra allocation/deallocation, although that could be avoided.
In order to support this, number() now returns a special temporary
return type, similarly to O(U)StringConcat, which allows delaying
the concatenation the same way.
Also similarly, the change of the return type in some cases requires
explicit cast to the actual string type. Usage of OString::getStr()
is so extensive in the codebase that I actually added it to the helper
class, after that it's only relatively few cases.
Change-Id: Iba6e158010e1e458089698c426803052b6f46031
Reviewed-on: https://gerrit.libreoffice.org/78873
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: I7b3a22584bb2e4d501f509ffcd80929feed23a4c
Reviewed-on: https://gerrit.libreoffice.org/79360
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: I3e57e815b538ad5749b4bab3d4ef8e295cbe116b
Reviewed-on: https://gerrit.libreoffice.org/79098
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I0ac21995315e136ae0035aeaf0f6a6d1e5f5811a
Reviewed-on: https://gerrit.libreoffice.org/79055
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I074794bdb6cb5ab3e16d4b78174f6aff39b589bc
Reviewed-on: https://gerrit.libreoffice.org/79031
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
To complete this:
https://gerrit.libreoffice.org/#/c/78312/
This is a massive replace for lines ending with
".." instead of "..."
It passed "make check" on Linux.
Change-Id: I07fa7b2e30ba9ea17a1f9a5e21c57216ba958efe
Reviewed-on: https://gerrit.libreoffice.org/78356
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Jenkins
|
|
and add move constructor, found by loplugin:noexceptmove
Change-Id: I89507113b354c4ae080f7107c996b55ab1285738
Reviewed-on: https://gerrit.libreoffice.org/78285
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
idea from mike kaganski
look for places where we can mark move operators as noexcept, which
makes some STL operations more efficient
Change-Id: Id732b89d1fcadd5ceb0ea2b9d159fed06136330f
Reviewed-on: https://gerrit.libreoffice.org/78251
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
...after 056e1fff2ed232f2a50db933fbade1c71c0c2a65 "Simplify code removing the
last segment from a URL"
Change-Id: I3abe84ada119356191d8df9c0a8ee62dcf18d108
Reviewed-on: https://gerrit.libreoffice.org/78228
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ic00c0a6788e65ba2b50e93d49592e67596354f96
Reviewed-on: https://gerrit.libreoffice.org/77998
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ica726584fe2691c9803976d23cba16d7f2a1f4bd
Reviewed-on: https://gerrit.libreoffice.org/77355
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: Ic472270afa13d2c96a4c7ccc185d183c3b7ade2c
Reviewed-on: https://gerrit.libreoffice.org/77277
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I6391e8caf4e344d410a31f45d391059498ebd928
Reviewed-on: https://gerrit.libreoffice.org/76635
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ie13b8b8f865e44f3746fdf79bf0b1b2cec2aba1d
Reviewed-on: https://gerrit.libreoffice.org/75845
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
LayoutConverter::calcAbsRectangle needed to be tweaked because
we now end up with a zero width/height instead of a large
negative number.
Change-Id: I81f04759a1d5bf6f44753a1701596796fad40567
Reviewed-on: https://gerrit.libreoffice.org/75610
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I5c7565309d380cdbe60a078d2c97f7dd1fae4274
Reviewed-on: https://gerrit.libreoffice.org/75517
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ia424b91149245907b045b43aa31a622e34e6e5bc
Reviewed-on: https://gerrit.libreoffice.org/75504
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
I tried making this assert, but there are just too many places where we
pass around empty rectangles, so rather just return the value of nLeft,
in a similar fashion to methods like Rectangle::TopLeft
Change-Id: I3377071ecae26f13e895ae411cd269f0bdbe0ef6
Reviewed-on: https://gerrit.libreoffice.org/75486
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ifef4c2ff967fdfbe122bca99e55d84e8e6c6a635
Reviewed-on: https://gerrit.libreoffice.org/75343
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
and make non-inline so it is easy to disable this for debugging, if need
be
Change-Id: I6feb94ca2f24246b96757575288c86c0b0c54227
Reviewed-on: https://gerrit.libreoffice.org/75342
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
and make non-inline so it is easy to disable this for debugging, if need
be
Change-Id: I2beae23bbdea36e91e0e367f9a94cbc35be3cd24
Reviewed-on: https://gerrit.libreoffice.org/75337
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
and make non-inline so it is easy to disable this for debugging, if need
be
Change-Id: I9a3f7a0356ab625681419f74af0b9884624f3642
Reviewed-on: https://gerrit.libreoffice.org/75336
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
and make non-inline so it is easy to disable this for debugging, if need
be
Change-Id: I69c717be91712b73e9d3b8f9c83d26305c052bd5
Reviewed-on: https://gerrit.libreoffice.org/75300
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
and make non-inline so it is easy to disable this for debugging, if need
be
Change-Id: Id529037e82b2fdd8c2120877a44fc7e069fc8406
Reviewed-on: https://gerrit.libreoffice.org/75298
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
The second parameter is unused
Change-Id: Iaf82ea24737a162c6aa8ce6b9e237f656a10020a
Reviewed-on: https://gerrit.libreoffice.org/75283
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I91c679506aad727c7f536e79e79a720db860b5ae
|
|
Adds CPU intrinsics detection in configure pass for compile time
detection and "cpuid" runtime detection of which CPU instruction
sets are available on the user device.
Change-Id: I0ee4d0b22a7c51f72796d43e7383a31d03b437ad
Reviewed-on: https://gerrit.libreoffice.org/75175
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|