4 ms·
It seems like a rare bout of sanity for strlcpy to have fallen out of favor, in the kernel. It never got into glibc, which was I guess another. But of course i
by ncmncm 4y ago
It seems like a rare bout of sanity for strlcpy to have fallen out of favor, in the kernel.
It never got into glibc, which was I guess another. But of course it is all over the BSDs, and not going anywhere AFaIK, more's the pity.
- kevin_thibedeau 4y agoGlibc isn't much of a standard of excellence for rational behavior considering they have malloc_info() dumping out XML rather than actually returning a useful data structure.
- ncmncm 4y agoMaybe "rare bout of sanity" is an unfamiliar concept?
- JdeBP 4y agoThe BSD kernels do not have nearly as many APIs that employ variable-length special-character-terminated strings that have to be parsed from human-readable forms, however. Whilst this is common for things like procfs in the Linux world, the BSDs favour general purpose interfaces like sysctl(3) where data are transferred in machine-parseable forms rather than human-readable ones. So "all over the BSDs" rather glosses over the fact that whilst common in applications code, there's less need for these sorts of string functions in the kernel. (And it is the Linux kernel that is the headlined subject here.) strlcpy() is in libkern, but it's not anywhere near as frequent in the kernel as it is in applications code.