summaryrefslogtreecommitdiffstats
path: root/src/vppinfra/string.h
AgeCommit message (Collapse)AuthorFilesLines
2022-02-10vppinfra: small optimization in clib_memset_u64Damjan Marion1-0/+8
Type: improvement Change-Id: I4b89c32c224caf8a3a4ac94b26ecefffd26c7038 Signed-off-by: Damjan Marion <damarion@cisco.com>
2022-02-10vppinfra:remove uXxY_is_greaterDamjan Marion1-6/+6
not needed, '>' works... Type: improvement Change-Id: I9bfbac787e8dca24e9b1bceda0922740eed26346 Signed-off-by: Damjan Marion <damarion@cisco.com>
2021-11-10vppinfra: new memcpy for x86_64Damjan Marion1-23/+9
Change-Id: I5a5055580479960ac53e3f989aa188faf57fb05d Type: improvement Signed-off-by: Damjan Marion <damarion@cisco.com>
2021-11-06vppinfra: move clib_count_equal_* codeDamjan Marion1-233/+0
Type: refactor Change-Id: Ib9e8abdbf745ad6563fc79c9ebb6b2ea65917d08 Signed-off-by: Damjan Marion <damarion@cisco.com>
2021-11-05unittest: gcc-11 errors for clib_strcpy, clib_strstr, clib_strcat, and ↵Steven Luong1-45/+0
clib_strncat There are 3 versions of the string functions. For example, for strcpy, they are 1. strcpy(dst, src) -- the legacy unsafe version 2. strcpy_s(dst, dmax, src) -- C11 safeC version which has an addition argument named dmax. 3. clib_strcpy(dst,src) -- clib version to enable legacy code that uses strcpy to make use of strcpy_s without adding the additional argument, dmax, which is required by the C11 safeC version. The implementation for the clib version is to artificially provide dmax to strcpy_s. In this case, it uses 4096 which assumes that if the legacy code works without blowing up, it is likely to work with the clib version without problem. gcc-11 is getting smarter by checking if dmax is within the object's boundary. When the object is declared as static array, it will flag a warning/error if dmax is out of bound for the object since the real size of dst can be determined at compile time. There is no way to find the real size of dst if the object is dynamically allocated at compile time. For this reason, we simply can't provide support for the clib version of the function anymore. If any code is using the clib version, the choice is to migrate to the safeC version. Type: fix Fixes: b0598497afde60146fe8480331c9f96e7a79475a Signed-off-by: Steven Luong <sluong@cisco.com> Change-Id: I99fa59c878331f995b734588cca3906a1d4782f5
2021-11-03vppinfra: strstr_s_inline checks string unterminated wrongSteven Luong1-1/+1
When checking whether s2 is unterminated, it uses s1max. It should use s2max. Type: fix Fixes: b0598497afde60146fe8480331c9f96e7a79475a Signed-off-by: Steven Luong <sluong@cisco.com> Change-Id: I8a0b8ceebc2dd18402a87274add528c3d085a95a
2021-04-27misc: fix dead storesDamjan Marion1-4/+1
Type: fix Change-Id: I08969e1c4a78f8ac92ec066a3b67e64dc931bc16 Signed-off-by: Damjan Marion <damarion@cisco.com>
2021-04-26vppinfra: clib_memcpy_u32() utilizing SIMD mask loads/storesDamjan Marion1-0/+2
Type: improvement Change-Id: I55c4688bd1feffae139ce12a66d15885373e5cd7 Signed-off-by: Damjan Marion <damarion@cisco.com>
2021-04-25vppinfra: add COMPILE_TIME_CONST() macroDamjan Marion1-1/+1
Type: improvement Change-Id: I10d7489f57bc60eb92049962b4e6ea84974f17b8 Signed-off-by: Damjan Marion <damarion@cisco.com>
2021-02-15vppinfra: fix memcpy undefined behaviourBenoît Ganne1-6/+21
Calling mem{cpy,move} with NULL pointers results in undefined behaviour. This in turns is exploited by GCC. For example, the sequence: memcpy (dst, src, n); if (!src) return; src[0] = 0xcafe; will be optimized as memcpy (dst, src, n); src[0] = 0xcafe; IOW the test for NULL is gone. vec_*() functions sometime call memcpy with NULL pointers and 0 length, triggering this optimization. For example, the sequence: vec_append(v1, v2); len = vec_len(v2); will crash if v2 is NULL, because the test for NULL pointer in vec_len() has been optimized out. This commit fixes occurrences of such undefined behaviour, and also introduces a memcpy wrapper to catch those in debug mode. Type: fix Change-Id: I175e2dd726a883f97cf7de3b15f66d4b237ddefd Signed-off-by: Benoît Ganne <bganne@cisco.com>
2020-08-03vppinfra: fix clib_count_equal_u8/16/32/64 overflowBenoît Ganne1-47/+30
Type: fix Change-Id: Id5ca868cd7a2abc9320206f0336aa3348f5906e3 Signed-off-by: Benoît Ganne <bganne@cisco.com>
2020-04-30build: rework x86 CPU variantsDamjan Marion1-1/+1
Type: improvement Change-Id: Ief243f88e654e578ef9b8060fcf535b364aececb Signed-off-by: Damjan Marion <damarion@cisco.com>
2019-05-13Fix typoIgor Mikhailov (imichail)1-1/+1
Change-Id: Ibc69195244bcc1e8e82c488fcd50b1eb2fcf81c0 Signed-off-by: Igor Mikhailov (imichail) <imichail@cisco.com>
2019-05-01Enable NEON instructions in memcpy_leLijian.Zhang1-1/+1
Neon version of memcpy_le gives better performance compared with memmove on aarch64 Change-Id: I44b487bb0795a6e70dd1e55bdde4a077773ec859 Signed-off-by: Lijian Zhang <Lijian.Zhang@arm.com> Reviewed-by: Sirshak Das <sirdas@arm.com>
2019-03-28Avoid overwrite in clib_memcpy_le{32,64}Damjan Marion1-27/+29
Change-Id: Id4a8b6a31fc3e88af2f075cb97c85d3f9b738d9e Signed-off-by: Damjan Marion <damarion@cisco.com>
2019-03-26ipsec: esp-encrypt reworkDamjan Marion1-0/+76
Change-Id: Ibe7f806b9d600994e83c9f1be526fdb0a1ef1833 Signed-off-by: Damjan Marion <damarion@cisco.com>
2019-01-18deprecate clib_memcpy64_x4Damjan Marion1-68/+0
Storing buffer in local template seems to be better option.... Change-Id: I1a2fdd68cb956f99a5b36d2cd810fc623e089bcf Signed-off-by: Damjan Marion <damarion@cisco.com>
2019-01-10strncpy_s_inline copies more bytes than necessarySteven1-2/+3
Given n equals to the maximum number of bytes to copy from src in the API, or the rough estimate strlen of src, strncpy_s_inline should not copy more than the number of bytes, computed by strlen(src), to dst if n is greater than strlen(src). The number of bytes to copy is computed by strnlen(src,n), not n. Change-Id: I088b46125d9776962750e121f1fbf441952efc2b Signed-off-by: Steven <sluong@cisco.com>
2018-12-05Improve strncpy_s src/dst overlap checkDave Barach1-2/+12
Let m = user estimate of the (max) src string length, low = smaller address of (src, dst), hi = larger address (src, dst). if (low + (m - 1) >= hi), we have a *potential* overlapping copy which is not allowed. Before we declare overlap - and return an error - retry the check with m = actual src string length. The resulting "test string" failure affected aarch64 (only) because of differences in test code stack variable placement / alignment. Change-Id: I2931d1ce2c61af3d3880075b033d2a4c4e421f09 Signed-off-by: Dave Barach <dave@barachs.net>
2018-12-02vppinfra: c11 safe string functionsSteven1-0/+713
Add memcmp_s, strcmp_s, strncmp_s, strcpy_s, strncpy_s, strcat_s, strncat_s, strtok_s, strnlen_s, and strstr_s C11 safe string API. For migrating extant unsafe API, add also the corresponding macro version of each safe API, clib_memcmp, clib_strcmp, etc. In general, the benefits of the safe string APIs are to provide null pointer checks, add additional argument to specify the string length of the passed string rather than relying on the null terminated character, and src/dest overlap checking for the the string copy operations. The macro version of the API takes the same number of arguments as the unsafe API to provide easy migration. However, it does not usually provide the full aformentioned benefits. In some cases, it is necessary to move to the safe API rather than using the macro in order to avoid some unpredictable problems such as accessing memory beyond what it is intended due to the lack of the passed string length. dbarach: add a "make test" vector, and a doxygen file header cookie. Change-Id: I5cd79b8928dcf76a79bf3f0b8cbc1a8f24942f4c Signed-off-by: Steven <sluong@cisco.com> Signed-off-by: Dave Barach <dave@barachs.net>
2018-11-14Remove c-11 memcpy checks from perf-critical codeDave Barach1-7/+17
Change-Id: Id4f37f5d4a03160572954a416efa1ef9b3d79ad1 Signed-off-by: Dave Barach <dave@barachs.net>
2018-10-23c11 safe string handling supportDave Barach1-3/+110
Change-Id: Ied34720ca5a6e6e717eea4e86003e854031b6eab Signed-off-by: Dave Barach <dave@barachs.net>
2018-10-10Integer underflow and out-of-bounds read (VPP-1442)Neale Ranns1-4/+4
Change-Id: Ife2a83b9d7f733f36e0e786ef79edcd394d7c0f9 Signed-off-by: Neale Ranns <nranns@cisco.com>
2018-10-04clib_count_equal_*: don't read of the end of a small array and init data ↵Neale Ranns1-8/+28
only if used (VPP-1429) Change-Id: I8afa57ecca590698d3430746968aa0a5b0070469 Signed-off-by: Neale Ranns <nranns@cisco.com>
2018-09-13vppinfra: optmize clib_count_equal functionsDamjan Marion1-60/+136
Change-Id: Ia4c79d560bfa1118d4683a89a1209a08c5f546b3 Signed-off-by: Damjan Marion <damarion@cisco.com>
2018-05-22vppinfra: add clib_count_equal_uXX and clib_memset_uXX functionsDamjan Marion1-0/+334
Change-Id: I56782652d8ef10304900cc293cfc0502689d800e Signed-off-by: Damjan Marion <damarion@cisco.com>
2017-12-14vppinfra: add AVX512 variant of clib_memcpyDamjan Marion1-2/+4
Taken from DPDK, also AVX2 variant updated to be in sync with DPDK version. Change-Id: I8a42e4141a5a1a8cfbee328b07bd0c9b38a9eb05 Signed-off-by: Damjan Marion <damarion@cisco.com>
2017-12-08vppinfra: fix issues depending on compilerSergio Gonzalez Monroy1-34/+34
It looks like different compiler versions produce different results for expressions like "(cast) ptr + inc". Use parenthesis to avoid such issues. Change-Id: I93a9883bf5fc05ae462df5b004817775f0739405 Signed-off-by: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>
2017-11-22use intel intrinsics in clib_memcpy64_x4Damjan Marion1-47/+54
While my original attmept was to write this function to be portable and work on non-x86 systems, seems that gcc-5 desn't respect aligment attribute and issues alligned vector insutruciton which causes crash. Change-Id: If165c8d482ac96f2b71959d326f9772b48097b48 Signed-off-by: Damjan Marion <damarion@cisco.com>
2017-11-13dpdk: introduce AVX512 variants of node functionsDamjan Marion1-0/+65
Change-Id: If581feca0d51d0420c971801aecdf9250c671b36 Signed-off-by: Damjan Marion <damarion@cisco.com>
2016-12-28Reorganize source tree to use single autotools instanceDamjan Marion1-0/+83
Change-Id: I7b51f88292e057c6443b12224486f2d0c9f8ae23 Signed-off-by: Damjan Marion <damarion@cisco.com>