On Fri, 31 Aug 2007, Timo Sirainen wrote: > > > > Perhaps because your patch was using a totally nonstandard and slow > > interface, and had nasty string declaration issues, as people even pointed > > out to you. > > Slow? Having a string library, and then implementing "str_append()" with a strlen() sounds pretty disgusting to me. Gcc could have optimized the strlen() away for constant string arguments, but since you made the thing out-of-line, it can't do that any more. So yes, I bet there are faster string libraries out there. > The code should be easy to verify to be secure, and with some kind of a safe > string API it's a lot easier than trying to figure out corner cases where > strcpy() calls break. I actually looked at the patches, and the "stringbuf()" thing was just too ugly to live. It was also nonportable, in that you use the reserved namespace (which we do extensively in the kernel, but that's an "embdedded" application that doesn't use system header files). So the API was anything but "safe". I think something like that could work, but it really should be done right, or not at all. Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
