aboutsummaryrefslogtreecommitdiffstats
path: root/src/plugins/unittest/string_test.c
AgeCommit message (Collapse)AuthorFilesLines
2024-03-12misc: remove GNU Indent directivesDamjan Marion1-2/+0
Type: refactor Change-Id: I5235bf3e9aff58af6ba2c14e8c6529c4fc9ec86c Signed-off-by: Damjan Marion <damarion@cisco.com>
2022-04-05vppinfra: refactor address sanitizerDamjan Marion1-1/+1
Type: refactor Change-Id: I5ca142ec1557d5b5c3806b43553ad9d3b5ea1112 Signed-off-by: Damjan Marion <damarion@cisco.com>
2021-11-06unittest: remove clib_count_equal_* testsDamjan Marion1-97/+3
Due to multiarch nature of that code, those tests doesn't bring much value. New tests will be addes as part of refactor. Type: refactor Change-Id: I41056dc99d08cd6ca38f9e00e8cf6a465c90edb7 Signed-off-by: Damjan Marion <damarion@cisco.com>
2021-11-05unittest: gcc-11 errors for clib_strcpy, clib_strstr, clib_strcat, and ↵Steven Luong1-340/+30
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
2020-08-03unittest: add clib_count_equal_u8/16/32/64 testsBenoît Ganne1-4/+100
Type: test Change-Id: I490c1b1a2fa49badda038e6be014c77b9bee6c56 Signed-off-by: Benoît Ganne <bganne@cisco.com>
2020-07-19unittest: keep ASAN happy for non-terminated string testsBenoît Ganne1-0/+2
Type: fix Change-Id: Iae9e84d4297acd54c909d3a8a39adafcd86b0a91 Signed-off-by: Benoît Ganne <bganne@cisco.com>
2020-04-04misc: strcpy be goneDave Barach1-1/+1
Causes static analysis "vulnerability" warnings Type: fix Ticket: VPP-1837 Signed-off-by: Dave Barach <dave@barachs.net> Change-Id: I272fa69251d70f62178e6dff0423c16f99937af1
2020-02-25unittest: Skip string test case for sizeof (src) > sizeof (dst)Steven Luong1-4/+13
coverity complains that the subject test may cause dst buffer overrun problem and it is right. The problem is when __builtin_constant_p (n) returns true, memcpy_s_inline skips all the errors checking and does the copy blindly. Please see the code in memcpy_s_inline. The fix is to skip the subject test when the aformentioned builtin function returns true. Type: fix Signed-off-by: Steven Luong <sluong@cisco.com> Change-Id: I50de91cc0c853a134b3bcf3b0cd8d45d7668b092
2019-02-27string_test: The dark side of coveritySteven Luong1-4/+0
Me: "Mr Coverity, I thought I fixed the dead code warning just few days ago in this file. Why are you still complaining about the same stuff to me?" Mr. Coverity: "Duh! But you are supposed to fix all occurences in the same file." Me: "Mr. Coverity, I didn't see you flag the warning in the other places last time?" Mr. Coverity: "Shh! That is the secret of my dark side!" Change-Id: I565eccd90bf1bb39c9881664d361f83396ca8bcc Signed-off-by: Steven Luong <sluong@cisco.com>
2019-02-21string_test: Coverity woeSteven Luong1-2/+0
Coverity complains about dead code as shown below and it is right. The fix is to simply remove the dead code. 503 if (v_indicator != indicator) CID 190173 (#3 of 3): Logically dead code (DEADCODE) dead_error_line: Execution cannot reach this statement: return -1;. 504 return -1; Change-Id: Ibca9e10451a4459db099bef5ecc6939474bdb903 Signed-off-by: Steven Luong <sluong@cisco.com>
2019-01-18Fix GCC 8 compiler warnings on strncpy's truncated copy on debian distroSteven Luong1-0/+12
For some reason, GCC 8 in debian is pickier than GCC 8 in ubuntu. It complains about things in strncpy like this /home/sluong/vpp/src/vlib/linux/pci.c:485:7: error: ‘strncpy’ output may be truncated copying 15 bytes from a string of length 255 [-Werror=stringop-truncation] strncpy (ifr.ifr_name, e->d_name, sizeof (ifr.ifr_name) - 1); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /home/sluong/vpp/src/vlib/linux/pci.c: At top level: It also complains similar things in string_test.c The fix in pci.c is to convert strncpy to use clib_strncpy The fix in string_test.c is condiational compile the complained code for GCC 8. Change-Id: Ic9341ca54ed7407210502197a28283bc42c26662 Signed-off-by: Steven Luong <sluong@cisco.com>
2019-01-10strncpy_s_inline copies more bytes than necessarySteven1-1/+10
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>
2019-01-07string_test: coverity woeSteven1-6/+0
Remove the needless tests and checks which coverity complains about in string_test.c Change-Id: I971650cada77136f06528a65625ef99bd3d7e915 Signed-off-by: Steven <sluong@cisco.com>
2018-12-14Revert gerrit 16429 to fix a Debian build-breakDave Barach1-22/+44
Change-Id: I9382bc981c25a29c293f7ddc6ed3d34130678696 Signed-off-by: Dave Barach <dave@barachs.net>
2018-12-14Fix compiling issue with GCC-8.x in string test functionsLijian.Zhang1-44/+22
Same pointer is passed to two or more restrict-qualified parameters of a function. vpp/src/plugins/unittest/string_test.c: In function ‘test_strcpy_s’: vpp/src/plugins/unittest/string_test.c:562:19: error: passing argument 1 to restrict-qualified parameter aliases with argument 3 [-Werror=restrict] err = strcpy_s (dst, s1size, dst); ^~~ ~~~ Change-Id: Ica06b457bbcbf2d552eec380976c37f9fd447b1c Signed-off-by: Lijian Zhang <Lijian.Zhang@arm.com> Reviewed-by: Sirshak Das <sirdas@arm.com>
2018-12-05Fix gcc-8 compile issues in string_test.cDave Barach1-1/+35
gcc-8 flunks a certain number of tests at compile time, so conditionally disable (negative) tests which won't even compile. Change-Id: Id7e85f38bc371623972efa6e2c8f9ee4717f5ff5 Signed-off-by: Dave Barach <dave@barachs.net>
2018-12-02vppinfra: c11 safe string functionsSteven1-25/+1559
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-10-23c11 safe string handling supportDave Barach1-0/+145
Change-Id: Ied34720ca5a6e6e717eea4e86003e854031b6eab Signed-off-by: Dave Barach <dave@barachs.net>