You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When we use the strnlen_s() function it calls _strnlen_s_chk(str,smax,BOS(str)).
BOS(str) will result in the length of the buffer if the compiler can estimate it: # define BOS(dest) __builtin_object_size((dest),1)
In _strnlen_s_chk() there is a this check:
if (unlikely(smax > strbos)) {
......
return 0;
}
If the given buffer length (smax) is bigger than the buffer size calculated by the compiler (strbos) it returns 0 and gives a warning.
The test suite does not include some standard cases to cover this, so it passes.
But a simple test like this would fail (would be nice in tests\test_strnlen_s.c:9
Uh, that's awfully wrong logic indeed. strnlen_s should not fail when the actual length is smaller than the maxlen. smax should only limit scanning on overlong strings, when there's still no 0. I have to check the specs on this. Does not make sense at all like this.
When we use the
strnlen_s()
function it calls_strnlen_s_chk(str,smax,BOS(str))
.BOS(str) will result in the length of the buffer if the compiler can estimate it:
# define BOS(dest) __builtin_object_size((dest),1)
In
_strnlen_s_chk()
there is a this check:If the given buffer length (smax) is bigger than the buffer size calculated by the compiler (strbos) it returns 0 and gives a warning.
The test suite does not include some standard cases to cover this, so it passes.
But a simple test like this would fail (would be nice in
tests\test_strnlen_s.c
:9That means: you need to know the string size to get the string size!
The text was updated successfully, but these errors were encountered: