| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
Change-Id: Ic804938fc352291d011800d21e549c10acac66fb
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Functions like QByteArray::at() assert the given index:
Q_ASSERT(i >= 0 && i < size();
These functions typically get inlined. Now if the index is
e.g. size() - 2, then gcc will emit an ugly warning in
client code ("assuming signed overflow does not occur when assuming
that (X - c) > X is always false").
This can be easily prevented by casting both sides of the second
comparison in the assertion to their unsigned type. The explicit
comparison to zero is then no longer necessary, since that condition
is tested implicitly by the other comparison due to unsigned arithmetic.
Change-Id: Ic7244e1fa5da00a47d1fe0ed56fb81c23d444dfe
Reviewed-by: hjk <qthjk@ovi.com>
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|
|
|
|
|
|
|
| |
Change copyrights and license headers from Nokia to Digia
Change-Id: If1cc974286d29fd01ec6c19dd4719a67f4c3f00e
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Reviewed-by: Sergio Ahumada <sergio.ahumada@digia.com>
|
|
|
|
|
|
|
|
|
|
|
| |
Both insert and replace have this overload, so one reason to add it
to append(), too, is consistency. But I can also make good use of
this overload in the the new QStringList::join(QChar) overload, so
it's actually useful in its own right.
Change-Id: Iccd48f9cb84831399e4db7e3e78eba25c0ced30d
Reviewed-by: João Abecasis <joao.abecasis@nokia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|
|
|
|
|
|
|
|
|
| |
All implicitly shared classes are by definition movable,
so this patch adds Q_DECLARE_TYPEINFO(Type, Q_MOVABLE_TYPE)
to Q_DECLARE_SHARED.
Change-Id: Idf8989ae1a7ed6d1ac13fccb7eaef7395a875350
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
|
|
|
|
|
|
|
|
|
|
|
| |
The extension doesn't work outside of function scopes, so a
function declaration such as
void foo(const QString &str = QStringLiteral("bar"));
would fail on certain gcc versions.
Change-Id: I2971301f2859edd3fc81b95dfa5a7c15f29e395c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
QString::localeAwareCompare() has always been a broken
way to support collation. The current implementation is
not even thread safe.
This adds a proper collation class that fixes the problems
and finally allows Qt to sort properly according to locale
rules.
The class is private for now, but is intendent to be made
public with 5.1
Change-Id: Idb4e75ff68a398c9813af622af884a90898d2be9
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|
|
|
|
|
|
| |
even if QT_NO_CAST_FROM_ASCII is defined.
Change-Id: I8c4deceedb6f3e3cd5bdf72d6e9d189c509c9ff3
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
to QLatin1String's compare operators that takes const char *s or QByteArray.
Such comparison leads to a potential misuse since QByteArray could contain any arbitrary data
in any arbitrary encoding and QLatin1String is used to only contain strings in UTF-8 -
they are just a different beasts aimed for different purposes, and since QT_NO_CAST_*_ASCII
disallow indirect conversions and require the user to know what he's doing,
let's be consistent here too.
Change-Id: I9bf5f326495157db8a6af064d6154961b7861a7e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|
|
|
|
| |
Change-Id: I05e0f866c632f2a7e966e6bae9c73eeb77d99217
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|
|
|
|
|
|
| |
Task-Id: QTBUG-24502
Change-Id: I360dee4dc68c165de0631ce4cf34e76fd873080e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|
|
|
|
|
|
| |
This is needed for the change that follows
Change-Id: I05611defe422fa4bbb5be27b102e39b1f61a1cbc
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|
|
|
|
|
|
|
| |
QString::from{Ascii|Latin1|Utf8|Local8Bit} does the string length calculation for us,
so let's use that and don't repeat the copy-paste bugs like the previous commit has fixed.
Change-Id: If0bced3ebaf75b56dde6be1266c47c3fbf89dab0
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Unify all it's overloads into a single private helper functionand use this new helper
where possible - so we could optimize all those operators in one step some later
(this also fixes `QBytArray("a\0b") < "a"` didn't respect the \0 while operator==
handles nul(s) correctly);
Add operators <,>,<=,>=(const char*) to QStringRef so that they doesn't create a temporary QString object;
Add missing QT_NO_CAST_FROM_ASCII
Change-Id: I8b6562a92fdb96e67aadee181f23f823d206f5fd
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make them call exactly their Latin 1 counterparts.
For the QString functions that take a single char, also use fromAscii
directly.
Change-Id: I87645aba6ab9cde34c1df3cbc3a979fbd9e91f9d
Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The fallback implementation of QStringLiteral did not (up to now)
enforce the need to use a literal. So it was possible to write:
const char *foo = "Hello";
QString s = QStringLiteral(foo);
Which would do the wrong thing and create s == "Hel" on 32-bit
platforms (sizeof(foo) == 4) or, wrose, s == "Hello\0XY" on 64-bit
platforms (sizeof(foo) == 8, X and Y are garbage).
This change enforces the need for a literal by producing errors on the
above cases, as well as when foo is a char array variable.
GCC:
error: expected ‘)’ before ‘foo’
Clang (abbreviated):
error: expected ')'
namespace X { QString x() { const char foo[42] = "Hello"; return QStringLiteral(foo); } }
^
note: to match this '('
^
ICC:
error: expected a ")"
namespace X { QString x() { const char foo[42] = "Hello"; return QStringLiteral(foo); } }
^
The first C++11 error currently is:
error: expected primary-expression before ‘enum’ (GCC)
error: expected a ")" (ICC)
Change-Id: I317173421dbd7404987601230456471c93b122ed
Reviewed-by: hjk <qthjk@ovi.com>
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changes all the containers that uses QtPrivate::RefCount
(QMap already had one), and QVariant
In Qt 4.8, it was pointless to have the move constructor because we did
not have quick way to re-initialize a null container. (shared_null still
needed to be refcounted)
But now that we have RefCount, and that the shared_null do not have
reference count, we can implement a fast move constructor that do not generate
code to increment the reference count.
Change-Id: I2bc3c6ae96983f08aa7b1c7cb98d44a89255160b
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@nokia.com>
|
|
|
|
|
|
|
|
|
|
|
| |
This commit matches the previous documentation commit that says that
the conversions are applied using to/fromUtf8.
Change-Id: I304e4d866ddedac5094fef8500cbeba299a02cb5
Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
Reviewed-by: hjk <qthjk@ovi.com>
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
|
|
|
|
|
| |
Change-Id: I42f817caf212b871cd00f976054381487b238d31
Reviewed-by: Kai Koehne <kai.koehne@nokia.com>
|
|
|
|
|
|
|
|
|
| |
This is a crude change, not the most efficient way. I'll clean up and
make it prettier later on, when I've had the chance to optimise the
UTF-8 codec too.
Change-Id: I78e30e8d3bddf6ad0210c9c4cedb9a7ce63d1a7d
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
|
|\
| |
| |
| | |
refs/staging/master
|
| |\
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
src/corelib/global/qglobal.cpp
src/corelib/global/qlogging.cpp
src/gui/kernel/qguiapplication.h
src/gui/kernel/qwindow.cpp
src/gui/kernel/qwindow.h
tests/auto/corelib/kernel/qvariant/tst_qvariant.cpp
Change-Id: I62a8805577a7940d4d36bed985eb3e7019d22f2e
|
| | |
| | |
| | |
| | |
| | |
| | | |
Change-Id: Ieadc60523a2bef61a088920576c65c720b11bfb9
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@nokia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Up until now, the macros would return an internal type that contained
the pointer to the data. This breaks code that tried to use the macros
with operators, like QStringBuilder but also when writing:
QStringList() << QStringLiteral("a") << QStringLiteral("b");
This change seems to work fine now and I can also verify that this
works:
const auto str = QStringLiteral("Hello");
Even though it creates a QString, which is non-POD and non-constexpr.
Change-Id: Iaf82af9bea4245513a1128ea54f9d2d3d785fb09
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@nokia.com>
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
libstdc++ requires wchar.h (which bionic provides), but it also requires
additional functionality which bionic does not provide, thus, std::wstring
proper basically doesn't exist.
Provide a compatibility shim so we can keep API intact. This feature existed in
a similar guise in the past, but was removed in
d868c9945a188d6ad22e0b7d6d24ac7fca00ab4e.
Change-Id: I6cab6f41d04ad9dde97e3ce73506f9d8a42043fb
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
c951908bc201afa59402967d50fa926212845fae added these overloads, but
did not properly use qstrnlen to get the size. This means we get
subtle errors because other methods do have them.
For example:
QByteArray ba("abc\0def", 7); // ba embedding a NUL
QString s1(ba);
QString s2 = QString::fromAscii(ba);
s1 == s2; // FAILS
QString s3;
s3.append(ba);
s3 == s2; // FAILS
Tested in an upcoming commit.
Change-Id: I22864521a42da789d522d7b75790696928d9ec32
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In conceptual terms, this change increments the Data::alloc member by
one for all strings allocated and maintained by these classes. Instances
initialized with fromRawData retain 0 as the member value, so they are
treated as immutable.
This brings QByteArray and QString closer to QVector, making it possible
for them to reference and share the same data in memory, in the future.
It also brings them closer to QArrayData.
In practical terms all comparisons to the alloc member were changed to
take into account that it also tracks the terminating null character.
Aside from the increment in the alloc member, there should be no user
visible changes.
Change-Id: I618f49022a9b1845754500c8f8706c72a68b9c7d
Reviewed-by: João Abecasis <joao.abecasis@nokia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|
|
|
|
| |
Change-Id: I27545e599a1831728e491a9fad1e52fa255535fc
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Just like qMalloc/qRealloc/qFree, there is absolutely no reason to wrap these
functions just to avoid an include, except to pay for it with worse runtime
performance.
On OS X, on byte sizes from 50 up to 1000, calling memset directly is 28-15%
faster(!) than adding an additional call to qMemSet. The advantage on sizes
above that is unmeasurable.
For qMemCopy, the benefits are a little more modest: 16-7%.
Change-Id: I98aa92bb765aea0448e3f20af42a039b369af0b3
Reviewed-by: Giuseppe D'Angelo <dangelog@gmail.com>
Reviewed-by: John Brooks <john.brooks@dereferenced.net>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
The parameter represents an allocation size and unsigned matches the
Q*Data::alloc member it ultimately represents (even if they currently
differ in accounting for the null).
There's still work up for grabs to ensure we avoid integer overflows
when growing.
Change-Id: Ib092fec37ec2ceed37bebfdc52e2de27b336328f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|
|
|
|
|
|
|
| |
QT_NO_STL is now no longer defined, so remove the conditionals and
select the STL side.
Change-Id: Ieedd248ae16e5a128b4ac287f850b3ebc8fb6181
Reviewed-by: João Abecasis <joao.abecasis@nokia.com>
|
|
|
|
|
|
|
|
| |
This avoids confusion with standard ::realloc.
Change-Id: Ibeccf2f702ec37161033febf4f3926bee8f7aea6
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Callers of QByteArray/QString::realloc() are still responsible for the
heuristics and decide whether to provide the "grow" hint, but
computation is centralized there.
With this change we also ensure growth takes into account the
terminating null. Previously, calls to qAllocMore took into account
header and string size, for left out the null, meaning we ended up
allocating ("nice-size" + Null).
Change-Id: Iad1536e7706cd2d446daee96859db9b01c5f9680
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|
|
|
|
|
| |
Change-Id: I196ec038ab7b648287e310525681f2d218059b51
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|
|
|
|
|
|
|
|
| |
This enables easier updating of those structs, by reducing the amount of
code that needs to be fixed. The common (and known) use cases are
covered by the two macros being introduced in each case.
Change-Id: I44981ca9b9b034f99238a11797b30bb85471cfb7
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There were two constuctors offering essentially the same functionality.
One taking the QStatic*Data<N> struct, the other what essentially
amounts to a pointer wrapper of that struct. The former was dropped and
the latter untemplatized and kept, as that is the most generic and
widely applicable. The template parameter in the wrapper was not very
useful as it essentially duplicated information that already maintained
in the struct, and there were no consistency checks to ensure they were
in sync.
In this case, using a wrapper is preferred over the use of naked
pointers both as a way to make explicit the transfer of ownership as
well as to avoid unintended conversions. By using the reference count
(even if only by calling deref() in the destructor), QByteArray and
QString must own their Data pointers.
Const qualification was dropped from the member variable in these
wrappers as it causes some compilers to emit warnings on the lack of
constructors, and because it isn't needed there.
To otherwise reduce noise, QStatic*Data<N> gained a member function to
directly access the const_cast'ed naked pointer. This plays nicely with
the above constructor. Its use also allows us to do further changes in
the QStatic*Data structs with fewer changes in remaining code. The
function has an assert on isStatic(), to ensure it is not inadvertently
used with data that requires ref-count operations.
With this change, the need for the private constructor taking a naked
Q*Data pointer is obviated and that was dropped too.
In updating QStringBuilder's QConcatenable specializations I noticed
they were broken (using data, instead of data()), so a test was added to
avoid this happening again in the future.
An unnecessary ref-count increment in QByteArray::clear was also
dropped.
Change-Id: I9b92fbaae726ab9807837e83d0d19812bf7db5ab
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Cleaned up preprocessor code to have a single definition for
QStaticStringData. A new qunicodechar typedef is introduced representing
a 2-byte integral type that can be used to represent a UTF-16 codepoint.
When QT_NO_UNICODE_LITERAL is not defined, QT_UNICODE_LITERAL converts a
US-ASCII string literal into a (native endian) UTF-16 string literal of
qunicodechar type.
Change-Id: I04822c4cdc0b240bc0fe113aba897348b7316932
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|
|
|
|
| |
Change-Id: I61ab71549799a5af8cce85e334245642a266c3c8
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
|
|\
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
src/corelib/tools/qvector.h
tests/auto/corelib/kernel/qmetatype/tst_qmetatype.cpp
Change-Id: I877256e95f3788e617437f4e9661a88047f38cd6
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
C++11 adds cbegin()/cend() functions for the same reason Qt has
constBegin()/constEnd(). This patch adds these functions to the
Qt containers with the same implementation as constBegin()/constEnd().
It also fixes the return types in the documentation of existing
constFind() functions (documentation only).
C++11 only adds cbegin()/cend() (and crbegin()/crend(), which Qt doesn't have).
In particular, it doesn't add cfind(), so I didn't supply these, even though
Qt comes with constFind().
This is a forward-port of https://qt.gitorious.org/qt/qt/merge_requests/1365.
Change-Id: Ida086b64246b24e25254eafbcb06c8e33388502b
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
qstring.h: In constructor ‘QLatin1String::QLatin1String(const QByteArray&)’:
qstring.h:667:129: error: ‘const char* QByteArray::constData() const’ is not ‘constexpr’
QByteArray has a destructor and therefore cannot be used in constexpr,
so do not mark it as constexpr
Change-Id: I037e9ae73a244660923eac791cc3e0082d1d7a63
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
| |
| |
| |
| |
| |
| |
| |
| | |
Added support for QString overloads taking a QRegularExpression.
Change-Id: I8608ab0b66e5fdd2e966992e1072cf1ef7883c8e
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
| |
| |
| |
| |
| |
| |
| |
| | |
This increases source compatibility when QT_NO_CAST_FROM_BYTEARRAY
is used.
Change-Id: Ie1a1cfa8acac2fa91aa8f217d91e22289be8b38f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|\|
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
src/corelib/kernel/qmetaobject.cpp
src/corelib/kernel/qvariant.cpp
src/tools/moc/moc.h
Change-Id: I2cd3d95b41d2636738c6b98064864941e3b0b4e6
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Certain versions of system headers will declare WCHAR_MAX like:
#define __WCHAR_MAX ( (wchar_t) - 1 )
#define WCHAR_MAX __WCHAR_MAX
In particular on ARM (see e.g.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=598937 )
In this case, defined(WCHAR_MAX) is true, but attempting to use the
value of WCHAR_MAX in a preprocessor expression will not give the
desired results - "wchar_t" is unknown to the preprocessor, so
WCHAR_MAX silently (without -Wundef) evaluates to ( (0) - 1 ) == -1.
A simple workaround is to avoid looking at WCHAR_MAX when the
superior __SIZEOF_WCHAR_T__ is defined.
Change-Id: I439b166cffb93416737ee19025fb6e8d51c27876
Reviewed-by: Bradley T. Hughes <bradley.hughes@nokia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
| |\
| | |
| | |
| | |
| | |
| | | |
Includes fixes for tst_qfiledialog2, tst_qtextedit autotests on mac.
Change-Id: I49cac26894d31291a8339ccc1eb80b6a940f0827
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The operator== and similar should not be member of the class. This
ensure a symertry.
Indeed, consider this code
string == string1 + string2;
string1 + string2 == string;
The first line compile fine even if QStringBuilder is used, because
QStringBuilder will be converted to QString implicitly.
But the second line do not compile if the operator== is a member of
QString, because the implicit conversion rules do not apply.
For this reason, the symetric operators should not be declared as
member.
Change-Id: I3f7c11fab45a9133f7a424bdfcb894f97da9282b
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
One of the more frequent uses for QByteArray::operator const char*()
is in passing a QByteArray to QString::fromLatin1().
But this is highly inefficient, since the bytearray already knows
its size, but since its demoted to a const char* in passing to
fromLatin1(), it forces the latter to call strlen() _again_.
The solution, then, is to add overloads for QByteArray that
pass the array's .size() as a second argument to the two-arg
fromLatin1() version.
Change-Id: I5ea1ad3c96d9e64167be53c0c418c7b7dba51f68
Reviewed-by: David Faure <faure@kde.org>
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
|
|\ \ \
| | |/
| |/|
| | | |
Change-Id: I97ba222435ff50a9e5422e6f2c73e4bb8d1b865c
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
GCC version < 3 which it was created for is not supported anymore.
Change-Id: I0b4df4c99600cacbaafbf0bc4270cd4978600956
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|