Add null terminator to tag->name string #372
Conversation
|
Thanks for this. This raises a larger issue: should the code simply fail in str_copy if the source string is larger than the buffer (modulo the null termination space)? I'll have to think about that. Unfortunately, C lets you ignore return values so even if I change the overall behavior of the function, the compiler is not going to help me find incorrect calls. The forcing of null termination on line 139 where you put a null character into the last byte of the buffer is sufficient. If the source string is shorter than the buffer size, then the underlying POSIX call will copy the string and null terminate it. If it is longer, then the forced null terminator will truncate and terminate the string. But this is where the above question comes up. str_copy can change the string during the copy. That is a non-obvious result and thus does not pass the principle of least surprize. Let me think about this. These wrappers were originally just minor code around underlying C library functions to make the APIs the same across platforms and to translate to library errors. But in this kind of case, the semantics are not clean. |
|
Ensure that strings are null-terminated. |
…rrect comparison (#383) * Add condition to fail tag creation when elem_count is a negative value. (#366) Fixes #365 * Change CI build to use Visual Studio 17 2022. Apparently version 16 is gone on Github? * Add checks to prevent out-of-bounds write on tag->encoded_name (#368) Fixes #367 * Update stable vs. unstable versions. * Bump version for next release. * Fix 378. Refactor condition var signal into common exit path of state SESSION_OPEN_SOCKET_START. * Fix 381. Incorrect comparison in loop guarding cond_wait from spurious wakeups. * Add null terminator to tag->name string (#372) Fixes #371 Co-authored-by: Tina Johnson <[email protected]>
Fixes #371