summaryrefslogtreecommitdiff
path: root/strbuf.c
AgeCommit message (Collapse)AuthorFilesLines
2008-12-17Add generic 'strbuf_readlink()' helper functionLibravatar Linus Torvalds1-0/+27
It was already what 'git apply' did in read_old_data(), just export it as a real function, and make it be more generic. In particular, this handles the case of the lstat() st_size data not matching the readlink() return value properly (which apparently happens at least on NTFS under Linux). But as a result of this you could also use the new function without even knowing how big the link is going to be, and it will allocate an appropriately sized buffer. So we pass in the st_size of the link as just a hint, rather than a fixed requirement. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-11-23add strbuf_expand_dict_cb(), a helper for simple casesLibravatar René Scharfe1-0/+16
The new callback function strbuf_expand_dict_cb() can be used together with strbuf_expand() if there is only a small number of placeholders for static replacement texts. It expects its dictionary as an array of placeholder+value pairs as context parameter, terminated by an entry with the placeholder member set to NULL. The new helper is intended to aid converting the remaining calls of interpolate(). strbuf_expand() is smaller, more flexible and can be used to go faster than interpolate(), so it should replace the latter. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-13Add some useful functions for strbuf manipulation.Libravatar Lukas Sandström1-0/+70
Signed-off-by: Lukas Sandström <lukass@etek.chalmers.se> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-13Make some strbuf_*() struct strbuf arguments const.Libravatar Lukas Sandström1-1/+1
Signed-off-by: Lukas Sandström <lukass@etek.chalmers.se> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-09Avoid a useless prefix lookup in strbuf_expand()Libravatar Marco Costalba1-11/+8
Currently, the --pretty=format prefix is looked up in a tight loop in strbuf_expand(), if prefix is found it is then used as argument for format_commit_item() that does another search by a switch statement to select the proper operation. Because the switch statement is already able to discard unknown matches we don't need the prefix lookup before to call format_commit_item(). Signed-off-by: Marco Costalba <mcostalba@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-03Uninline prefixcmp()Libravatar Junio C Hamano1-0/+9
Now the routine is an open-coded loop that avoids an extra strlen() in the previous implementation, it got a bit too big to be inlined. Uninlining it makes code footprint smaller but the result still retains the avoidance of strlen() cost. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-14Merge branch 'rs/pretty'Libravatar Junio C Hamano1-0/+31
* rs/pretty: Fix preprocessor logic that determines the availablity of strchrnul(). Simplify strchrnul() compat code --format=pretty: avoid calculating expensive expansions twice add strbuf_adddup() --pretty=format: parse commit message only once --pretty=format: on-demand format expansion Add strchrnul()
2007-11-14Handle broken vsnprintf implementations in strbufLibravatar Shawn O. Pearce1-3/+4
Solaris 9's vsnprintf implementation returns -1 if we pass it a buffer of length 0. The only way to get it to give us the actual length necessary for the formatted string is to grow the buffer out to have at least 1 byte available in the strbuf and then ask it to compute the length. If the available space is 0 I'm growing it out by 64 to ensure we will get an accurate length estimate from all implementations. Some callers may need to grow the strbuf again but 64 should be a reasonable enough initial growth. We also no longer silently fail to append to the string when we are faced with a broken vsnprintf implementation. On Solaris 9 this silent failure caused me to no longer be able to execute "git clone" as we tried to exec the empty string rather than "git-clone". Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-11add strbuf_adddup()Libravatar René Scharfe1-0/+7
Add a new function, strbuf_adddup(), that appends a duplicate of a part of a struct strbuf to end of the latter. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-09--pretty=format: on-demand format expansionLibravatar René Scharfe1-0/+24
Some of the --pretty=format placeholders expansions are expensive to calculate. This is made worse by the current code's use of interpolate(), which requires _all_ placeholders are to be prepared up front. One way to speed this up is to check which placeholders are present in the format string and to prepare only the expansions that are needed. That still leaves the allocation overhead of interpolate(). Another way is to use a callback based approach together with the strbuf library to keep allocations to a minimum and avoid string copies. That's what this patch does. It introduces a new strbuf function, strbuf_expand(). The function takes a format string, list of placeholder strings, a user supplied function 'fn', and an opaque pointer 'context' to tell 'fn' what thingy to operate on. The function 'fn' is expected to accept a strbuf, a parsed placeholder string and the 'context' pointer, and append the interpolated value for the 'context' thingy, according to the format specified by the placeholder. Thanks to Pierre Habouzit for his suggestion to use strchrnul() and the code surrounding its callsite. And thanks to Junio for most of this commit message. :) Here my measurements of most of Paul Mackerras' test cases that highlighted the performance problem (best of three runs): (master) $ time git log --pretty=oneline >/dev/null real 0m0.390s user 0m0.340s sys 0m0.040s (master) $ time git log --pretty=raw >/dev/null real 0m0.434s user 0m0.408s sys 0m0.016s (master) $ time git log --pretty="format:%H {%P} %ct" >/dev/null real 0m1.347s user 0m0.080s sys 0m1.256s (interp_find_active -- Dscho) $ time ./git log --pretty="format:%H {%P} %ct" >/dev/null real 0m0.694s user 0m0.020s sys 0m0.672s (strbuf_expand -- this patch) $ time ./git log --pretty="format:%H {%P} %ct" >/dev/null real 0m0.395s user 0m0.352s sys 0m0.028s Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-29strbuf_read_file enhancement, and use it.Libravatar Pierre Habouzit1-2/+2
* make strbuf_read_file take a size hint (works like strbuf_read) * use it in a couple of places. Signed-off-by: Pierre Habouzit <madcoder@debian.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-29strbuf change: be sure ->buf is never ever NULL.Libravatar Pierre Habouzit1-11/+19
For that purpose, the ->buf is always initialized with a char * buf living in the strbuf module. It is made a char * so that we can sloppily accept things that perform: sb->buf[0] = '\0', and because you can't pass "" as an initializer for ->buf without making gcc unhappy for very good reasons. strbuf_init/_detach/_grow have been fixed to trust ->alloc and not ->buf anymore. as a consequence strbuf_detach is _mandatory_ to detach a buffer, copying ->buf isn't an option anymore, if ->buf is going to escape from the scope, and eventually be free'd. API changes: * strbuf_setlen now always works, so just make strbuf_reset a convenience macro. * strbuf_detatch takes a size_t* optional argument (meaning it can be NULL) to copy the buffer's len, as it was needed for this refactor to make the code more readable, and working like the callers. Signed-off-by: Pierre Habouzit <madcoder@debian.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-27Add strbuf_read_file().Libravatar Kristian Høgsberg1-0/+15
Signed-off-by: Kristian Høgsberg <krh@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-26Add strbuf_cmp.Libravatar Pierre Habouzit1-0/+12
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-20strbuf API additions and enhancements.Libravatar Pierre Habouzit1-10/+10
Add strbuf_remove, change strbuf_insert: As both are special cases of strbuf_splice, implement them as such. gcc is able to do the math and generate almost optimal code this way. Add strbuf_swap: Exchange the values of its arguments. Use it in fast-import.c Also fix spacing issues in strbuf.h Signed-off-by: Pierre Habouzit <madcoder@debian.org>
2007-09-18Drop strbuf's 'eof' marker, and make read_line a first class citizen.Libravatar Pierre Habouzit1-12/+8
read_line is now strbuf_getline, and is a first class citizen, it returns 0 when reading a line worked, EOF else. The ->eof marker was used non-locally by fast-import.c, mimic the same behaviour using a static int in "read_next_command", that now returns -1 on EOF, and avoids to call strbuf_getline when it's in EOF state. Also no longer automagically strbuf_release the buffer, it's counter intuitive and breaks fast-import in a very subtle way. Note: being at EOF implies that command_buf.len == 0. Signed-off-by: Pierre Habouzit <madcoder@debian.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-16Now that cache.h needs strbuf.h, remove useless includes.Libravatar Pierre Habouzit1-1/+0
Signed-off-by: Pierre Habouzit <madcoder@debian.org> Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-16New strbuf APIs: splice and attach.Libravatar Pierre Habouzit1-15/+52
* strbuf_splice replace a portion of the buffer with another. * strbuf_attach replace a strbuf buffer with the given one, that should be malloc'ed. Then it enforces strbuf's invariants. If alloc > len, then this function has negligible cost, else it will perform a realloc, possibly with a cost. Also some style issues are fixed now. Signed-off-by: Pierre Habouzit <madcoder@debian.org> Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-10Strbuf API extensions and fixes.Libravatar Pierre Habouzit1-6/+27
* Add strbuf_rtrim to remove trailing spaces. * Add strbuf_insert to insert data at a given position. * Off-by one fix in strbuf_addf: strbuf_avail() does not counts the final \0 so the overflow test for snprintf is the strict comparison. This is not critical as the growth mechanism chosen will always allocate _more_ memory than asked, so the second test will not fail. It's some kind of miracle though. * Add size extension hints for strbuf_init and strbuf_read. If 0, default applies, else: + initial buffer has the given size for strbuf_init. + first growth checks it has at least this size rather than the default 8192. Signed-off-by: Pierre Habouzit <madcoder@debian.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-06Rework strbuf API and semantics.Libravatar Pierre Habouzit1-14/+87
The gory details are explained in strbuf.h. The change of semantics this patch enforces is that the embeded buffer has always a '\0' character after its last byte, to always make it a C-string. The offs-by-one changes are all related to that very change. A strbuf can be used to store byte arrays, or as an extended string library. The `buf' member can be passed to any C legacy string function, because strbuf operations always ensure there is a terminating \0 at the end of the buffer, not accounted in the `len' field of the structure. A strbuf can be used to generate a string/buffer whose final size is not really known, and then "strbuf_detach" can be used to get the built buffer, and keep the wrapping "strbuf" structure usable for further work again. Other interesting feature: strbuf_grow(sb, size) ensure that there is enough allocated space in `sb' to put `size' new octets of data in the buffer. It helps avoiding reallocating data for nothing when the problem the strbuf helps to solve has a known typical size. Signed-off-by: Pierre Habouzit <madcoder@debian.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-07War on whitespaceLibravatar Junio C Hamano1-1/+0
This uses "git-apply --whitespace=strip" to fix whitespace errors that have crept in to our source files over time. There are a few files that need to have trailing whitespaces (most notably, test vectors). The results still passes the test, and build result in Documentation/ area is unchanged. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2006-12-20simplify inclusion of system header files.Libravatar Junio C Hamano1-3/+1
This is a mechanical clean-up of the way *.c files include system header files. (1) sources under compat/, platform sha-1 implementations, and xdelta code are exempt from the following rules; (2) the first #include must be "git-compat-util.h" or one of our own header file that includes it first (e.g. config.h, builtin.h, pkt-line.h); (3) system headers that are included in "git-compat-util.h" need not be included in individual C source files. (4) "git-compat-util.h" does not have to include subsystem specific header files (e.g. expat.h). Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-05-20sparse cleanupLibravatar Linus Torvalds1-1/+1
Fix various things that sparse complains about: - use NULL instead of 0 - make sure we declare everything properly, or mark it static - use proper function declarations ("fn(void)" instead of "fn()") Sparse is always right.
2005-05-19[PATCH] fix strbuf take #2Libravatar Junio C Hamano1-0/+2
I just remembered why I placed that bogus "sb->len ==0 implies sb->eof" condition there. We need at least something like this to catch the normal EOF (that is, line termination immediately followed by EOF) case. "if (feof(fp))" fires when we have already read the eof, not when we are about read it. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-18strbuf: allow zero-length linesLibravatar Linus Torvalds1-2/+0
They aren't EOF.
2005-04-26[PATCH] introduce xmalloc and xreallocLibravatar Christopher Li1-1/+2
Introduce xmalloc and xrealloc to die gracefully with a descriptive message when out of memory, rather than taking a SIGSEGV. Signed-off-by: Christopher Li<chrislgit@chrisli.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-25[PATCH] Introduce diff-tree-helper.Libravatar Junio C Hamano1-0/+43
This patch introduces a new program, diff-tree-helper. It reads output from diff-cache and diff-tree, and produces a patch file. The diff format customization can be done the same way the show-diff uses; the same external diff interface introduced by the previous patch to drive diff from show-diff is used so this is not surprising. It is used like the following examples: $ diff-cache --cached -z <tree> | diff-tree-helper -z -R paths... $ diff-tree -r -z <tree1> <tree2> | diff-tree-helper -z paths... - As usual, the use of the -z flag is recommended in the script to pass NUL-terminated filenames through the pipe between commands. - The -R flag is used to generate reverse diff. It does not matter for diff-tree case, but it is sometimes useful to get a patch in the desired direction out of diff-cache. - The paths parameters are used to restrict the paths that appears in the output. Again this is useful to use with diff-cache, which, unlike diff-tree, does not take such paths restriction parameters. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>