net.c: switch strncat(3) use to strlcat(3)#156
Conversation
This will be leveraged in the next commit, resolving complaints from compilers about the pathological case where strncat(3) is used in net.c . Obtained from: (DragonFlyBSD.org: lib/libc/string/strlcpy.c @ 667231f1) Signed-off-by: Enji Cooper <yaneurabeya@gmail.com>
|
@ckujau: FYI. |
strlcat(3), unlike its predecessor (strncat(3)), NUL terminates buffers when the buffer length meets or exceeds the provided `dstsize`. Leveraging strlcat(3) instead of strncat(3) squashes compiler warnings, and ensures the buffer is properly NUL terminated in the pathological case. Signed-off-by: Enji Cooper <yaneurabeya@gmail.com>
|
but you copied strlcpy, not strlcat
…On June 5, 2026 8:37:41 PM CDT, Enji Cooper ***@***.***> wrote:
strlcat(3), unlike its predecessor (strncat(3)), NUL terminates buffers
when the length are exceeded. Leveraging strlcat(3) instead squashes
compiler warnings when the pathological case is hit with strncat(3)
where the code (prior to this change) would not properly NUL terminate
the buffer, leading to a potential buffer access problem.
This is an alternative approach to the solution suggested in #77.
You can view, comment on, or merge this pull request online at:
#156
-- Commit Summary --
* Import strlcat(3) implementation from DragonFlyBSD
* net.c: switch strncat(3) use to strlcat(3)
-- File Changes --
M bsd/dma/Makefile (2)
M dfcompat.c (56)
M net.c (2)
-- Patch Links --
https://github.com/corecode/dma/pull/156.patch
https://github.com/corecode/dma/pull/156.diff
--
Reply to this email directly or view it on GitHub:
#156
You are receiving this because you are subscribed to this thread.
Message ID: ***@***.***>
|
JFC. I’ll fix that when I get back home. |
strlcat(3), unlike its predecessor (strncat(3)), NUL terminates buffers
when the buffer length meets or exceeds the provided
dstsize.Leveraging strlcat(3) instead of strncat(3) squashes compiler warnings,
and ensures the buffer is properly NUL terminated in the pathological case.
This is an alternative approach to the solution suggested in #77.