summaryrefslogtreecommitdiffstats
path: root/src/plugins/unittest/string_test.c
AgeCommit message (Collapse)AuthorFilesLines
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>