summaryrefslogtreecommitdiffstats
path: root/src/corelib/text/qbytearray.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Add the note about data size to QByteArray::operator=(const char*)Alexey Edelev2024-03-271-0/+3
| | | | | | | | | | Add the note about the way the str size is determined when using QByteArray::operator=(const char*). Pick-to: 6.7 6.6 6.5 Change-Id: I39b2d0fc2967832622fbf0c11b3ff6c7ff99b8f2 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
* Bootstrap: remove QDataStreamThiago Macieira2024-03-131-1/+1
| | | | | | | | | | | It was only used by the cmake_automoc_parser so it would write a 64-bit in big-endian format. So bypass QDataStream and write it native endianness. Change-Id: I01ec3c774d9943adb903fffd17b79c78e56db4cf Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* QByteArray: use comparison helper macrosIvan Solovev2024-03-021-52/+60
| | | | | | | | | | | | | | | | | | Replace the existing friend relational operators with the macros. Add the previously-missing relational opertors with QChar and char16_t. This allows to remove the last dummy relational operators and the macros to generate them in tst_qstringapisymmetry. Because of a bug in libstdc++[0], we have to explicitly keep the QBA vs QBA relational operators even in C++20 mode. This problem is specific to QByteArray, because it is convertible to const void *. [0]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114153 Task-number: QTBUG-117661 Change-Id: Iac7f81cd3274331b7c7695a51803321b511361c0 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QString: use comparison helper macros - comparison with byte arrays [2/3]Ivan Solovev2024-03-021-84/+0
| | | | | | | | | | | | | | | | | | Use the comparison helper macros to replace the member relational operators for comparison with QByteArray and const char *. As QString and QByteArray are exported, we cannot simply remove the inline methods, so wrap them into QT_CORE_REMOVED_SINCE. Add relational operators with QByteArrayView. Provide more unit-tests for the comparison with the byte array types. This enables operator<=> for QString vs byte arrays in C++20 builds. Task-number: QTBUG-117661 Change-Id: I305343e1b6c5d78b10f2976573db4e904ba6b44b Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QString/QByteArray: add slice() methodsAhmad Samir2024-02-291-7/+36
| | | | | | | | | [ChangeLog][QtCore][QString/QByteArray] Added slice() methods that work like sliced(), but modify the string/byte-array they are called on. Task-number: QTBUG-99218 Change-Id: I3075562983ef123d9aa022a2304c7e774cf2ea42 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Containers: add max_size()Giuseppe D'Angelo2024-02-271-2/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | One more method for STL compatibility. This one is particularly subtle as it's required by the `reservable-container` concept: https://eel.is/c++draft/ranges#range.utility.conv.general-3 Without this concept, ranges::to won't reserve() before copying the elements (out of a sized range which isn't a common_range). Implementation notes: there were already a couple of constants denoting the maximum QByteArray and QString size. Centralize that implementation in QTypedArrayData, so that QList can use it too. The maximum allocation size (private constant) needs a even more central place so that even QVLA can use it. Lacking anything better, I've put it in qcontainerfwd.h. Since our containers aren't allocator-aware, I can make max_size() a static member, and replace the existing constants throughout the rest of qtbase. (I can't kill them yet as they're used by other submodules.) [ChangeLog][QtCore][QList] Added max_size(). [ChangeLog][QtCore][QString] Added max_size(). [ChangeLog][QtCore][QByteArray] Added max_size(). [ChangeLog][QtCore][QVarLengthArray] Added max_size(). Change-Id: I176142e31b998f4f787c96333894b8f6653eb70d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QByteArray/QString: add resizeForOverwriteGiuseppe D'Angelo2024-02-161-0/+15
| | | | | | | | | | | | | | | For these classes it's not really a new feature, but exposing the current resize() behavior (which does uninitialized resizes) under a proper name. Changing the existing behavior for resize() is a behavioral break that we can only likely afford in Qt 7. [ChangeLog][QtCore][QString] Added resizeForOverwrite(). [ChangeLog][QtCore][QByteArray] Added resizeForOverwrite(). Change-Id: I15b3104aee2bc29d23e91d97b0e64f87612d0099 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Doc: Fix QDoc warnings for overloadsPaul Wicking2024-02-141-0/+1
| | | | | Change-Id: I9a77b6ea0026748c7f97f73b327118f7a9212d52 Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
* QDataStream: add a new SizeLimitExceeded status codeIvan Solovev2024-01-261-1/+1
| | | | | | | | | | | | | | | | | | This status is supposed to be used when the stream tries to read or write more data than it is supported by the current platform. For example, reading more than 2 GiB of data on a 32-bit platform will result into this status, but it will work fine on a 64-bit platform. This patch uses the new status in read operations. Amends fd48ce0b73c74dafd5db27bc1f2752ef665df7ef Found in 6.7 API review Pick-to: 6.7 Change-Id: I675b1ee25fafba174ce8f94c3470dbb7893d6d9e Reviewed-by: Marc Mutz <marc.mutz@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QString & QByteArray: ensure QT_NO_CAST_* are not defined on WindowsThiago Macieira2024-01-231-0/+8
| | | | | | | | | | | | | | | | | | | | | | We can't have those macros defined while compiling the headers on Windows (mainly MSVC, but there are some corner cases that apply to MinGW too) because the inline functions must be emitted and added to the DLL export table. Trying to undefine (as qchar.cpp did) won't work in builds with PCH or in CMake Unified builds, because the headers in question will have already been included. So instead just #error out. qchar.cpp is #included in qstring.cpp so it no longer needs this. For Qt 7, we'll un-export the class (see next commit). Note: it's possible we only need a single .cpp including the headers and compiled without these macros for the export to kick in. That could be removed_api.cpp, because that can never be part of PCH or Unified sources. But I have not confirmed this is the case. Task-number: QTBUG-121356 Change-Id: I5dd50a1a7ca5424d9e7afffd17acba32fb27f1ca Reviewed-by: Ivan Solovev <ivan.solovev@qt.io> Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* QString/QByteArray: further inline the most common indexOf operationsThiago Macieira2023-12-211-20/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the case of QString, the vast majority of searches are case- sensitive, so by inlining we make the user code call qustrchr() directly instead of QtPrivate::findString(). In the case of QByteArray, the call is to memchr(), which being a compiler intrinsic, may itself be inlined or even just resolved at compile time. In both cases, a great deal of searches use from=0. Benchmark for QByteArray; before: 8.83207052 nsecs per iteration 22.01568546 CPU cycles per iteration, 2.49 GHz 60.00000331 instructions per iteration, 2.725 instr/cycle 21.00000281 branch instructions per iteration, 2.38 G/sec After: 6.42561493 nsecs per iteration 16.01623130 CPU cycles per iteration, 2.49 GHz 49.00000261 instructions per iteration, 3.059 instr/cycle 18.00000211 branch instructions per iteration, 2.8 G/sec This shaves 6 cycles in the execution and 11 instructions (3 of which were branches), slightly improving the IPC raito, for the QByteArray case. For QByteArrayView, there are 2 fewer instructions (1 a branch), but the number of cycles is the same at 16. Task-number: QTBUG-119750 Change-Id: Ica7a43f6147b49c187ccfffd179e2204ebb6a348 Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* QByteArray: inline QByteArray::indexOf() and use a char overloadThiago Macieira2023-12-211-10/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | QByteArray::indexOf() had the best implementation of the two *because* it was out-of-line, in qbytearray.cpp. The compiler could thus see the body of the QtPrivate::findByteArray() function and inline it, with constant-propagation, so only findCharHelper() was expanded and we had a fast path towards memchr(). On the other hand, QByteArrayView::indexOf() was inline, so the compiler emitted the call to QtPrivate::findByteArray() in user code, causing the full function to be executed. We fix that by adding a char overload for QtPrivate::findByteArray() and lastIndexOf(), so we get to memchr() more quickly. Also, inline QByteArray::indexOf() and lastIndexOf(). Before: QByteArray::indexOf(): 8.83287376 nsecs per iteration 22.01766832 CPU cycles per iteration, 2.49 GHz 62.00000330 instructions per iteration, 2.816 instr/cycle 21.00000281 branch instructions per iteration, 2.38 G/sec QByteArrayView::indexOf(): 9.64034694 nsecs per iteration 24.03001151 CPU cycles per iteration, 2.49 GHz 68.00000355 instructions per iteration, 2.830 instr/cycle 23.00000306 branch instructions per iteration, 2.39 G/sec After (same result for both, requires recompilation): 8.83207052 nsecs per iteration 22.01568546 CPU cycles per iteration, 2.49 GHz 60.00000331 instructions per iteration, 2.725 instr/cycle 21.00000281 branch instructions per iteration, 2.38 G/sec The inlining appears to have cut 2 instructions, but the effect is not measurable in this benchmark (the entire code is in cache and the Branch Predictor is probably primed). Fixes: QTBUG-119750 Change-Id: Ica7a43f6147b49c187ccfffd179e1cb4b306fc62 Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* Doc: Fix \fn template arguments for Qt CoreLuca Di Sera2023-11-301-1/+1
| | | | | | | | | Upcoming changes to QDoc require accurate definition for template arguments in \fn commands. Task-number: QTBUG-118080 Change-Id: I64d50919bc6ffab61ef5ead553d1da99d63a9f21 Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
* QString/QByteArray: add lvalue and rvalue overloads of left/mid/rightThiago Macieira2023-10-251-19/+30
| | | | | | | | | | | | The first/last/sliced API may be what we suggest users use, but the vast majority of the installed codebase uses left/mid/right because they've been available since time immemorial. An additional benefit of this is to make left() and right() available as inline methods. Change-Id: Ifeb6206a9fa04424964bfffd1788383817ed906c Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* QString/QBA: add lvalue and rvalue overloads to first/last/sliced/choppedThiago Macieira2023-10-251-5/+18
| | | | | | | | | | | | Those ought to have been the original implementation, when they were added in commit 38096a3d7040edac4f769270d2402ff4e39d7694, for Qt 6.0. Because these classes are exported, we need to provide the previous only implementations for MSVC. All other compilers would provide inline or emit local, out-of-line copies. Change-Id: Ifeb6206a9fa04424964bfffd178836a2ae56157d Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* QArrayDataPointer: add an allocating constructorThiago Macieira2023-10-251-7/+7
| | | | | | | | It's by far the most common use, so having to call two things is just cumbersome. Change-Id: I79e700614d034281bf55fffd178f454c4e31929e Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Add support for containers > 4 Gi elements in QDataStreamØystein Heskestad2023-10-231-6/+12
| | | | | | | | | | | | The format is changed from 6.7 to support more than UINT32_MAX - 1 elements. The format used to have a quint32 size. Now if the size is larger or equal to 0xfffffffe (2^32 -2) the old size is an extend value 0xfffffffe followed by one quint64 with the actual value. The 32 bit size with all bits set is still used as null value. Fixes: QTBUG-105034 Change-Id: I62188be170fe779022ad58ab84a54b1eaf46e5d9 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QByteArray: use constexpr moreAnton Kudryavtsev2023-10-061-8/+8
| | | | | | Change-Id: I89bfb51659df798bc4dfa37d764b56ea8a289fbf Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* QBA::replace: avoid unconditional detachAnton Kudryavtsev2023-09-121-6/+5
| | | | | | | | | | Let's find needle and then do detach While touching code, replace raw loop with algorithm and add early out: compare before and after args Change-Id: I22403fd3d6920d941b65e79f44b46e49a9777dc5 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QString/QByteArray: fix append() wrt. raw dataMårten Nordheim2023-08-211-1/+4
| | | | | | | | | | | | | | | | | | | | When appending to an empty string or byte array, we optimize and copy the internal pointer. But if the other string/byte array was created with fromRawData this might be temporary data on the stack/heap and might be de-allocated or overwritten before the string/byte array is used or is forced to make a deep-copy. This would lead to incorrect data being used. This is easy to overlook if you plan to append multiple strings together, potentially supplied through an argument. Upon appending a second string it would make a full copy, but there might not be a guarantee for that. So, it's hard for users to avoid this pitfall! Fixes: QTBUG-115752 Pick-to: 6.6 6.5 6.2 Change-Id: Ia9aa5f463121c2ce2e0e8eee8a6c8612b7297f2b Reviewed-by: Ahmad Samir <a.samirh78@gmail.com> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Deprecate Q_ASSUME()Thiago Macieira2023-08-141-1/+1
| | | | | | | | | | | | | | | | | | | | We've known for a long time that this is producing worse code with GCC because of how we implemented in Q_ASSUME_IMPL(). So bite the bullet and actually deprecate the macro, replacing all extant Q_ASSUME() with Q_ASSERT(). The replacement is in C++23. Backporting the support onto Q_ASSUME_IMPL was previously rejected by reviewers. [ChangeLog][Deprecation Notice] The Q_ASSUME() macro is deprecated. This macro has different side-effects depending on the compiler used (GCC compared to Clang and MSVC), and there are certain conditions under which GCC is known to produce worse code than if the macro was absent. To give a hint to the compiler for optimizations, use the C++23 [[assume]] attribute. Change-Id: I80612a7d275c41f1baf0fffd177a3a4ad819fb2d Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* QByteArray: use new assign() in operator=(const char *)Dennis Oberst2023-08-111-8/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | operator=(~) and assign(~) share similar names but, until now, have not shared the same functionality. This patch introduces the usage of QByteArray::assign() within the non-sharing assignment operator to effectively boost efficiency by reusing the available capacity. Since these assignment operators are frequently used in many places, both within Qt and non-Qt code, this patch comes with benchmarks. The preview of the benchmark results are compared with this patch and before this patch. The findings indicate a slight enhancement in performance associated with the assignment operator. Despite the results displaying only a minor improvement, progress has been made. Therefore use assign(QByteArrayView) as replacement. (x86_64-little_endian-lp64 shared (dynamic) release build (O3); by gcc 13.2.1, endeavouros ; 13th Gen Intel(R) Core(TM) i9-13900K benchmarks executed with -perf -iterations 1000000 * The last value at the EOL represent the string size. QByteArray &operator=(const char *ch) (current) 65 cycles/iter; 317 instructions/iter; 16.0 nsec/iter (5) 71.7 cycles/iter; 383 instructions/iter; 13.0 nsec/iter (10) 59.8 cycles/iter; 318 instructions/iter; 10.9 nsec/iter (20) 70.8 cycles/iter; 340 instructions/iter; 12.9 nsec/iter (50) 80.2 cycles/iter; 419 instructions/iter; 14.6 nsec/iter (100) 164.2 cycles/iter; 899 instructions/iter; 29.9 nsec/iter (500) 260.5 cycles/iter; 1522 instructions/iter; 45.6 nsec/iter (1'000) QByteArray &operator=(const char *ch) (before) 66.8 cycles/iter; 317 instructions/iter; 16.9 nsec/iter (5) 76.5 cycles/iter; 383 instructions/iter; 13.9 nsec/iter (10) 63.7 cycles/iter; 318 instructions/iter; 11.6 nsec/iter (20) 71.6 cycles/iter; 344 instructions/iter; 13.0 nsec/iter (50) 77.5 cycles/iter; 419 instructions/iter; 14.1 nsec/iter (100) 143.4 cycles/iter; 893 instructions/iter; 26.1 nsec/iter (500) 270.8 cycles/iter; 1516 instructions/iter; 48.2 nsec/iter (1'000) Task-number: QTBUG-106201 Change-Id: I0745c33f0f61f1d844a60960cc55f565320d5945 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QByteArray: change append(QByteArray) to match QStringBuilder behaviorAhmad Samir2023-08-031-3/+8
| | | | | | | | | | | | I.e. concatenating a null byte array and an empty-but-not-null byte array should result in an empty-but-not-null byte array. This matches the behavior of QString::append(QString) too. Fixes: QTBUG-114238 Pick-to: 6.6 Change-Id: Id36d10ee09c08041b7dabda102df48ca6d413d8b Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QLocaleData:: port bytearray/stringTo{U}LongLong to QSimpleParsedNumberAhmad Samir2023-07-221-8/+6
| | | | | | Change-Id: I97fe38d9b676cf92003a7323ebb5f56b9b79abad Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* qstringalgorithms: refactor trimmed_helper_positionsAhmad Samir2023-07-221-3/+1
| | | | | | | | | Take by const Str&, trimming a container/view of characters means removing whitespace from the beginning and end, so the two args were always cbegin() and cend(). Change-Id: Iac0eda59341f1981204d11013d591013eae3c4e0 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QByteArray: add STL-style assign()Dennis Oberst2023-06-021-0/+67
| | | | | | | | | | | | | | | | | Implemented assign() methods for QByteArray to align with the criteria of std::basic_string, addressing the previously missing functionality. This is a subset of the overloads provided by the standard. Reference: https://en.cppreference.com/w/cpp/string/basic_string/assign [ChangeLog][QtCore][QByteArray] Added assign(). Fixes: QTBUG-106199 Change-Id: I899b14d74e8f774face8690303efb8610ead95b5 Reviewed-by: Marc Mutz <marc.mutz@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Remove unused IS_RAW_DATA() macros from q{string,bytearray}.cppEdward Welbourne2023-05-311-3/+0
| | | | | | | | | | They were made redundant at Qt 6, so now they're just defined and undefined. Don't even do that any more. Change-Id: Ic4a4a4c39c50c9af417ea6c52be5f69a2d4856c6 Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Doc: Make QByteArray(qsizetype size, Qt::Initialization) doc publicTopi Reinio2023-05-151-2/+0
| | | | | | | | | | The constructor that doesn't explicitly initialize the content of the array can be useful in some cases. Pick-to: 6.5 Fixes: QTBUG-111582 Change-Id: Icc4bd753f1944a91be70316a7303bb822f79d472 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QString/QByteArray::op>>: don't assume clear() makes the container isNull()Marc Mutz2023-05-041-1/+3
| | | | | | | | | | | | | | | | This is something we may want to change at some point, so be explicit and assign a null container instead of relying on clear(). Add a comment that was present in the QString, but missing in the QByteArray implementation. Pick-to: 6.5 Task-number: QTBUG-31283 Task-number: QTBUG-60745 Change-Id: I10d82b8a0c67fff314af526c7b7e0f247c3405fd Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
* Implement qstrncpy() in terms of std::strncat()Marc Mutz2023-03-101-10/+3
| | | | | | | | | | | | | | | | This has the advantage that we're only copying strlen(src) characters, like in the strncpy_s() case, not fill all of [dst,len) with NULs, like strncpy() is wont to do. [ChangeLog][Important Behavior Changes][qstrncpy()] On non-Windows platforms, no longer writes to all bytes of the target buffer, but stops after the terminating NUL. This was already the behavior on Windows. Change-Id: Ic86206f418affae6d0d88dfe79537eeb833a7daa Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* qstrncpy(): document that we don't implement strncpy() fill-all-[dst,len)Marc Mutz2023-03-031-0/+4
| | | | | | | | | The Windows version didn't, ever since we started using strncpy_s(), and we might change the non-Windows version, too. Pick-to: 6.5 6.4 6.2 5.15 Change-Id: Iee1c09674d296be806d4be42b1891940120b4a01 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* qstrncpy: NUL-terminate even when src is nullptrMarc Mutz2023-02-221-7/+9
| | | | | | | | | | | | | | | | | | | | | The goal of this function is to ensure that dst is _always_ NUL-terminated. The only exception is if there's no space to write even one NUL byte, of course, but not when src is nullptr but dst would have space. Update the docs to the new behavior and make them more precise. Fix a test that assumed qstrncpy() would not write to dst for (dst, nullptr, 10). [ChangeLog][QtCore][qstrncpy()] Now NUL-terminates the target buffer even when the source pointer is nullptr, provided the target buffer has space for at least one byte. Pick-to: 6.5 6.4 6.2 5.15 Change-Id: I7806d8c71e260f8f02b79af7b6ce94f23599dd69 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Rename QBA::{to,from}Uint8Array() → {to,from}EcmaUint8Array()Marc Mutz2023-02-211-4/+4
| | | | | | | | | Found in API review: from/toUintArray() is too generic a name, make sure its name gives enough context. Pick-to: 6.5 Change-Id: Ie10ff06ae11a5e168c4c91b60a9698a41d0429fc Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* wasm: fix to/from Uint8Array documentatonMorten Sørvig2023-02-141-4/+4
| | | | | | | | | Functions generally don't have a \brief section. The Uint8Array conversion functions were introduced in 6.5. Pick-to: 6.5 Change-Id: I1d366d7506327128f7eedd71310e570ade6fc66c Reviewed-by: Mikołaj Boc <Mikolaj.Boc@qt.io>
* QtCore: Fix some macro clashesFriedemann Kleint2023-01-311-0/+3
| | | | | | | | | | | | | | The macro decode() in qurlquery.cpp clashes with the static helper function decode() in qurlrecode.cpp. The macro encode() in qurlquery.cpp clashes with QStringEncoder::encode(). Macro CBOR_ENCODER_WRITER_CONTROL is defined with various values in 3rdparty/tinycbor and qcborstreamwriter.cpp. Pick-to: 6.5 Task-number: QTBUG-109394 Change-Id: I8fdf696863e5b1e6fb0c5607b2dd5b46427b9104 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Use more documentation snippets for QString and its siblingsAhmad Samir2023-01-011-3/+5
| | | | | | Pick-to: 6.5 Change-Id: Ia569806b586923473f68b9fe1d98a3628ba46a58 Reviewed-by: Paul Wicking <paul.wicking@qt.io>
* QContainerTools: add q_points_into_range overloadAhmad Samir2022-12-111-4/+4
| | | | | | | | | Looking at the use-cases of the already existing q_points_into_range overload, all of them can be ported to the new one (i.e. all of them were using range [begin, end)). Change-Id: I4bfdd68271512b88a9800a16237ff967a367eaeb Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* wasm: add native QByteArray conversion functionsMorten Sørvig2022-12-051-0/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add functions which converts to and from JavaScript data arrays: static QByteArray::fromUint8Array(emscripten::val array) emscripten::val QByteArray::toUint8Array() const with corresponding internal qstdweb API: static Uint8Array Uint8Array::copyFrom(const QByteArray &buffer) QByteArray Uint8Array::copyToQByteArray() const Both functions will make a copy of the data, i.e. there is no shared reference counting. They take and return Uint8Array typed array views, via emscripten::val JavaScript object references. Unlike other native conversion functions, these have the special property that the data referenced by the native Uint8Array exists outside the heap memory area. This means we can’t e.g. memcpy the data. However, the heap is itself a JavaScript ArrayBuffer, and we can create a Uint8Array view to the buffer owned by the QByteArray, and then use JavaScript API to copy. See the qstdweb::Uint8Array::copy() implementation. That also means that a fromRawUint8Array() variant (which does not copy) is not possible to implement, since we can’t create a pointer to the source data. The inverse toRawUint8Array() is implementable - it would return a Uint8Array view which references the heap’s ArrayBuffer. However, this may turn out to be ill-advised, since Emscripten will create a new ArrayBuffer if/when it resizes the heap. In any case this left for a future expansion. Change-Id: Icaf48fd17ea8686bf04cb523cc1eb581ce63ed34 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
* QString/QByteArray: de-pessimize op+ [1/2]: non-const return typesMarc Mutz2022-12-011-5/+5
| | | | | | | | | | | | | | const return types prevent move semantics, so drop the const. This is BC, because the operators are all inline free functions. In particular, they're not exported (MSVC mangles the return type). [ChangeLog][QtCore][QString/QByteArray] operator+ no longer returns a const object, enabling move-semantics on the return value, but also hidden detaches. Change-Id: Ifc18f6b1df1e3840f57b2521949dbade8e11fd76 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QLocale: make qt_doubleToAscii not have output argumentsThiago Macieira2022-11-161-5/+3
| | | | | | | | | Repeat the last commit, now for floating point parsing (and without the benchmarking). Like the last commit, removes one category of parsing, when we would return an advanced parsing pointer and still fail. Change-Id: Ieba79baf5ac34264a988fffd1726759a2359828d Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* QString, QByteArray: add removeAt/First/Last() convenience methodsAhmad Samir2022-11-161-0/+32
| | | | | | | | | | | Requested in codereview.qt-project.org/c/qt/qtbase/+/441770 [ChangeLog][QtCore][Text] Add removeAt/First/Last() convenience methods to QString and QByteArray Change-Id: I48a803e456e70cc51d51726a5e3aa7c125aedb1c Reviewed-by: Paul Wicking <paul.wicking@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QByteArray: don't detach in remove()Ahmad Samir2022-11-041-3/+12
| | | | | | | | | | | | | | - If this bytearray isn't shared call d->erase() as needed - if it's shared, instead of detaching, create a new bytearray, and copy all characters except for the ones that would be removed See task for details. Adjust unittest to test both code paths. Task-number: QTBUG-106182 Change-Id: I806e4d1707004345a2472e056905fbf675f765ab Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QString, QByteArray: add erase(iterator) methodAhmad Samir2022-11-031-0/+15
| | | | | | Fixes: QTBUG-106182 Change-Id: Idc74cc643b90252838ca1a9ca40a330315da421f Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QByteArray: in/deflate: compare different types as size_tMårten Nordheim2022-10-311-1/+2
| | | | | | | | | | | | | Compiling for android a certain configuration warns about comparisons between types of different signedness. On 32-bit we cannot cast the unsigned type to qsizetype and on x64 we cannot cast the qsizetype to Zlib's type (both potentially truncating). So, cast both to size_t before comparing Pick-to: 6.4 6.2 Change-Id: I0dd40c875b1a61a64f0574f0209a8549fc73164a Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* Port qCompress() to zstream/deflate()Marc Mutz2022-10-171-33/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The zlib convenience API we've been using so far has two problems: - On Windows-64, where sizeof(long) == 4, the use of ulong for sizes meant that we could not compress data compressable on other 64-bit platforms (Unix). While zstream also uses ulong, being a stream API, it allows feeding data in chunks. The total_in and total_out members are only required for gzip compression and are otherwise just informational. They're unsigned, so their overflow does not cause UB. In summary, using zstream + deflate() allows us to compress more than 4GiB of data even on Windows-64. - On all platforms, we always allocated the output buffer in such a way as to accommodate the pathological case of random, incompressible data, so the output buffer was larger than the input. Using zstream + deflate(), we can start with a smaller buffer, then let zlib pick up where it left off when it ran out of output buffer space, saving memory in the common case that compression meaningfully reduces the size. To avoid the first few rounds of reallocations, we continue to use zlib's compressBound() for input less than 256KiB. This completely fixes the compression side of QTBUG-106542 and QTBUG-104972. Pick-to: 6.4 6.3 6.2 Fixes: QTBUG-104972 Fixes: QTBUG-106542 Change-Id: Ia7e6c38403906b35462480fd611b482f05a5c59c Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* Port qUncompress() to zstream/inflate()Marc Mutz2022-10-161-50/+118
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The zlib convenience API we've been using so far has two problems: - On Windows-64, where sizeof(long) == 4, the use of ulong for sizes meant that we could not uncompress data compressed on other 64-bit platforms (Unix). While zstream also uses ulong, being a stream API, it allows feeding data in chunks. The total_in and total_out members are only required for gzip compression and are otherwise just informational. They're unsigned, so their overflow does not cause UB. In summary, using zstream + inflate() allows us to decompress more than 4GiB of data even on Windows-64. - On all platforms, if the size hint in the header was too short, we'd double the output buffer size and try again, from scratch. Using zstream + inflate(), we still need to reallocate, but we can then let zlib pick up where it left off when it ran out of output buffer space. In all but the most pathological cases, copying the already-decoded data instead of re-decoding it again should be faster, esp. if QArrayData uses realloc() instead of malloc() + free() to grow the buffer. We also now directly allocate at least as much output buffer as we have input, to cut the first few rounds of reallocations when the expectedSize was created, as qCompress still does, using modulo arithmetic mod 4GiB instead of saturation arithmethic. Factor the growing of the output buffer into a wrapper function, flate(), which can be reused when porting qCompress(). This completely fixes the uncompression side of QTBUG-106542 and QTBUG-104972. Pick-to: 6.4 6.3 6.2 Task-number: QTBUG-104972 Task-number: QTBUG-106542 Change-Id: I97f55ea322c24db1ac48b31c16855bc91708e7e2 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Long live Q_UNREACHABLE_RETURN()!Marc Mutz2022-10-151-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a combination of Q_UNREACHABLE() with a return statement. ATM, the return statement is unconditionally included. If we notice that some compilers warn about return after __builtin_unreachable(), then we can map Q_UNREACHABLE_RETURN(...) to Q_UNREACHABLE() without having to touch all the code that uses explicit Q_UNREACHABLE() + return. The fact that Boost has BOOST_UNREACHABLE_RETURN() indicates that there are compilers that complain about a lack of return after Q_UNREACHABLE (we know that MSVC, ICC, and GHS are among them), as well as compilers that complained about a return being present (Coverity). Take this opportunity to properly adapt to Coverity, by leaving out the return statement on this compiler. Apply the macro around the code base, using a clang-tidy transformer rule: const std::string unr = "unr", val = "val", ret = "ret"; auto makeUnreachableReturn = cat("Q_UNREACHABLE_RETURN(", ifBound(val, cat(node(val)), cat("")), ")"); auto ignoringSwitchCases = [](auto stmt) { return anyOf(stmt, switchCase(subStmt(stmt))); }; makeRule( stmt(ignoringSwitchCases(stmt(isExpandedFromMacro("Q_UNREACHABLE")).bind(unr)), nextStmt(returnStmt(optionally(hasReturnValue(expr().bind(val)))).bind(ret))), {changeTo(node(unr), cat(makeUnreachableReturn, ";")), // TODO: why is the ; lost w/o this? changeTo(node(ret), cat(""))}, cat("use ", makeUnreachableReturn)) ); where nextStmt() is copied from some upstream clang-tidy check's private implementation and subStmt() is a private matcher that gives access to SwitchCase's SubStmt. A.k.a. qt-use-unreachable-return. There were some false positives, suppressed them with NOLINTNEXTLINE. They're not really false positiives, it's just that Clang sees the world in one way and if conditonal compilation (#if) differs for other compilers, Clang doesn't know better. This is an artifact of matching two consecutive statements. I haven't figured out how to remove the empty line left by the deletion of the return statement, if it, indeed, was on a separate line, so post-processed the patch to remove all the lines matching ^\+ *$ from the diff: git commit -am meep git reset --hard HEAD^ git diff HEAD..HEAD@{1} | sed '/^\+ *$/d' | recountdiff - | patch -p1 [ChangeLog][QtCore][QtAssert] Added Q_UNREACHABLE_RETURN() macro. Change-Id: I9782939f16091c964f25b7826e1c0dbd13a71305 Reviewed-by: Marc Mutz <marc.mutz@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* qCompress: use saturation, not truncation, for the size headerMarc Mutz2022-09-261-1/+1
| | | | | | | | | | | | This provides a better size hint than the pseudo-random mod 4GiB number used before. In particular, it will make the Qt 5 implementation fail fast, because UINT_MAX will be recognized as a non-representable size right away. Pick-to: 6.4 6.3 6.2 Task-number: QTBUG-104972 Change-Id: I6010f558eb71bbf02fb0f71bee1b3b1a15ec6e3f Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* qCompress: return null, not empty, for OOMMarc Mutz2022-09-261-3/+2
| | | | | | | | | | | | | | | | | While this is a behavior change, we never documented that we'd return an empty instead of a null QByteArray in this situation. Indeed, returning bazip, with its fully-preserved capacity, is an expensive way of signalling an error condition. Conclude that this is not what the original author wanted and return a default-constructed byte array instead, leaving bazip and its excess capacity to be destroyed before the return from the function. Pick-to: 6.4 6.3 6.2 Task-number: QTBUG-104972 Task-number: QTBUG-106542 Change-Id: I2ee1fc6fdbb9da28f1987b16915516b51bb348c3 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* qUn/Compress: reject negative lengthsMarc Mutz2022-09-231-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | In qCompress, we've been calculating postive len values out of them, only to fail at random points later, possibly running into UB. Fail early instead. In qUncompress, we've been catching negative values, and reported them indiscriminately as "invalid data". Use a better warning message instead. By rights, nbytes ≥ 0 would be a precondition of both functions (which we would Q_ASSERT() on), but seeing we're picking this back into LTS branches, I found it prudent to use a non-fatal way to signal the precondition violation. If and when we keep these functions for Qt 7, it will be as an overload that takes QByteArrayView, in which case nbytes ≥ 0 enters as a hard precondition via the QByteArrayView constructor, so there appears to be no need to pre-program a Q_ASSERT() for Qt 7.0. Pick-to: 6.4 6.3 6.2 Task-number: QTBUG-104972 Task-number: QTBUG-106542 Change-Id: I6a1b25fe12d31e3d4c845033cad320832976f83c Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-06 11:18:25 +0000