Date: Thu, 15 Aug 2002 15:38:49 -0700 From: Maxime Henrion <mux@freebsd.org> To: arch@FreeBSD.org Cc: Terry Lambert <tlambert2@mindspring.com>, brooks@freebsd.org Subject: Re: kernel strlcpy Message-ID: <20020815223849.GH14155@elvis.mu.org> In-Reply-To: <3D5C22E2.33A82B55@mindspring.com> References: <20020815122641.B21334@Odin.AC.HMC.Edu> <20020815193028.GF14155@elvis.mu.org> <3D5C22E2.33A82B55@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert wrote: > Maxime Henrion wrote: > > Brooks Davis wrote: > > > I'd like to import strlcpy into libkern. It's obviously the right > > > function for setting the if_xname member of struct ifnet from the > > > device. > > > > Yes, please! We waited far too long for this, there are a lot of places > > in the kernel that really need strlcpy(). > > No, please. It encourages idiots to do string processing in > the kernel, when you should be carrying around this crap in > user space, instead. It doesn't encourage people to do string processing in the kernel any more, since we already have strcpy() and strncpy(). Yes, generally speaking, string processing in the kernel is bad, but using str?cpy() is not necessarily bad. Whatever you do, we have some information represented by strings in the kernel, and we sometimes need to copy these strings. We're not parsing files here. :-) Going against strlcpy() doesn't help at all here; everywhere we need to copy strings we're forced to work around strncpy() which is a broken interface, and there is still the risk someone will write code using strncpy() without taking care of that problem, thus creating a possible security flaw. > I think Linux did the right thing when they limited string > copied in the kernel to file path name components. > > Other than "mount" (the system call that ate the world), > and "sysctl" (the debug subsystem that ate the world), there's > not a lot of real valid use for string manipulation in the > kernel. I tend to agree; I think there are cases of string manipulation in the kernel that would be avoided. But as you already said, there *are* valid uses for these functions. That's why we shouldn't make life so hard for these subsystems. Forcing them to use strncpy() while they could use strlcpy() doesn't make people more conscious of the problems we have with other subsystems using string manipulation when they shouldn't. It just makes programming harder for the valid cases. Cheers, Maxime To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020815223849.GH14155>