aboutsummaryrefslogtreecommitdiff
path: root/git-p4.py
diff options
context:
space:
mode:
authorJeff King <peff@peff.net>2016-07-08 05:12:22 -0400
committerJunio C Hamano <gitster@pobox.com>2016-07-08 09:47:29 -0700
commit52563d7ecc8f3f38cb1c0521294c5f6a0a475637 (patch)
tree1e29e32d8955c4c796794773c032b980f673b1dc /git-p4.py
parentee861e0f78367ff0e94feeb42f721ef83ceec251 (diff)
downloadgit-52563d7ecc8f3f38cb1c0521294c5f6a0a475637.tar.gz
git-52563d7ecc8f3f38cb1c0521294c5f6a0a475637.tar.xz
write_file: add pointer+len variant
There are many callsites which could use write_file, but for which it is a little awkward because they have a strbuf or other pointer/len combo. Specifically: 1. write_file() takes a format string, so we have to use "%s" or "%.*s", which are ugly. 2. Using any form of "%s" does not handle embedded NULs in the output. That probably doesn't matter for our call-sites, but it's nicer not to have to worry. 3. It's less efficient; we format into another strbuf just to do the write. That's probably not measurably slow for our uses, but it's simply inelegant. We can fix this by providing a helper to write out the formatted buffer, and just calling it from write_file(). Note that we don't do the usual "complete with a newline" that write_file does. If the caller has their own buffer, there's a reasonable chance they're doing something more complicated than a single line, and they can call strbuf_complete_line() themselves. We could go even further and add strbuf_write_file(), but it doesn't save much: - write_file_buf(path, sb.buf, sb.len); + strbuf_write_file(&sb, path); It would also be somewhat asymmetric with strbuf_read_file, which actually returns errors rather than dying (and the error handling is most of the benefit of write_file() in the first place). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'git-p4.py')
0 files changed, 0 insertions, 0 deletions