Jeff King <peff@xxxxxxxx> writes: > And here is what the "quote embedded NULs" patch would look like on top. > It's actually pretty straightforward, but the more I think of it, the > more I think it is probably not worthwhile. Not only are we quoting > paths, which should not have embedded NULs, but it requires that the > caller always pass the length explicitly, and clearly we are not doing > that all or even most of the time. So while this would fix the low-level > "this function quotes an arbitrary string" case, for it to be of any use > all of the code paths leading to it would need to be audited to handle > NUL-embedded strings. Thanks; I think your analysis is very sound. The current callers do not care (for a good reason). They are dealing with a pathname, and either they are feeding a string on which there is a pathname followed by something else and they know where that something else begins (they give maxlen because they don't want to or cannot NUL terminate the string in place while calling this function), or they know they want to quote to the end of the string but they haven't counted how long it is (they say "I don't care---just quote to the end"). In either way, they don't expect giving too long a maxlen will go beyond the end of the string past the terminating NUL. Unless we document "this function is to C-quote a (portion of a) string, either to the end or up to the given length", however, future callers may incorrectly assume that with length the function can be fed anything and would C-quote that piece of memory. The argument name "const char *name" already suggests that is not an arbitrary binary rubbish, changing that to "str" would probably make that a bit stronger documentation, or we could explicitly say "this is a (early part of a) NUL-terminated string" in a comment. But your one-liner patch would actually be a smaller change than any of them and makes the whole problem disappear; wouldn't it be a far better solution? -- 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