{"thread":{"id":"36551","subject":"[PATCH 1/2] strbuf: Use _rtrim and _ltrim in strbuf_trim","startedAt":"2014-04-30T08:58:06Z","lastAt":"2014-04-30T17:11:06Z","messageCount":3,"participants":["Brian Gesiak","Jeff King"],"isPatch":true,"patchVersion":1,"patchTotal":2},"messages":[{"id":"240277","messageId":"1398848287-77109-1-git-send-email-modocache@gmail.com","threadId":"36551","inReplyTo":null,"subject":"[PATCH 1/2] strbuf: Use _rtrim and _ltrim in strbuf_trim","fromName":"Brian Gesiak","fromEmail":"modocache@gmail.com","sentAt":"2014-04-30T08:58:06Z","receivedAt":"2014-04-30T08:58:06Z","isPatch":true,"sender":{"key":"modocache@gmail.com","avatar":"https://avatars.githubusercontent.com/u/552921?v=4"},"body":"strbuf_trim strips whitespace from the end, then the beginning of a\nstrbuf. Those operations are duplicated in strbuf_rtrim and\nstrbuf_ltrim.\n\nReplace strbuf_trim implementation with calls to strbuf_rtrim,\nthen strbuf_ltrim.\n\nSigned-off-by: Brian Gesiak <modocache@gmail.com>\n---\n\nThis is tangential to my GSoC project; I noticed the duplication\nand thought it could be remedied.\n\n strbuf.c | 11 ++---------\n 1 file changed, 2 insertions(+), 9 deletions(-)\n\ndiff --git a/strbuf.c b/strbuf.c\nindex 83caf4a..382cf68 100644\n--- a/strbuf.c\n+++ b/strbuf.c\n@@ -96,15 +96,8 @@ void strbuf_grow(struct strbuf *sb, size_t extra)\n \n void strbuf_trim(struct strbuf *sb)\n {\n-\tchar *b = sb->buf;\n-\twhile (sb->len > 0 && isspace((unsigned char)sb->buf[sb->len - 1]))\n-\t\tsb->len--;\n-\twhile (sb->len > 0 && isspace(*b)) {\n-\t\tb++;\n-\t\tsb->len--;\n-\t}\n-\tmemmove(sb->buf, b, sb->len);\n-\tsb->buf[sb->len] = '\\0';\n+\tstrbuf_rtrim(sb);\n+\tstrbuf_ltrim(sb);\n }\n void strbuf_rtrim(struct strbuf *sb)\n {\n-- \n1.9.2.507.g779792a\n"},{"id":"240278","messageId":"1398848287-77109-2-git-send-email-modocache@gmail.com","threadId":"36551","inReplyTo":"1398848287-77109-1-git-send-email-modocache@gmail.com","subject":"[PATCH 2/2] api-strbuf.txt: Add docs for _trim and _ltrim","fromName":"Brian Gesiak","fromEmail":"modocache@gmail.com","sentAt":"2014-04-30T08:58:07Z","receivedAt":"2014-04-30T08:58:07Z","isPatch":true,"sender":{"key":"modocache@gmail.com","avatar":"https://avatars.githubusercontent.com/u/552921?v=4"},"body":"API documentation for strbuf does not document strbuf_trim or\nstrbuf_ltrim. Add documentation for these two functions.\n\nSigned-off-by: Brian Gesiak <modocache@gmail.com>\n---\n Documentation/technical/api-strbuf.txt | 9 +++++++++\n 1 file changed, 9 insertions(+)\n\ndiff --git a/Documentation/technical/api-strbuf.txt b/Documentation/technical/api-strbuf.txt\nindex 3350d97..4396be9 100644\n--- a/Documentation/technical/api-strbuf.txt\n+++ b/Documentation/technical/api-strbuf.txt\n@@ -121,10 +121,19 @@ Functions\n \n * Related to the contents of the buffer\n \n+`strbuf_trim`::\n+\n+\tStrip whitespace from the beginning and end of a string.\n+\tEquivalent to performing `strbuf_rtrim()` followed by `strbuf_ltrim()`.\n+\n `strbuf_rtrim`::\n \n \tStrip whitespace from the end of a string.\n \n+`strbuf_ltrim`::\n+\n+\tStrip whitespace from the beginning of a string.\n+\n `strbuf_cmp`::\n \n \tCompare two buffers. Returns an integer less than, equal to, or greater\n-- \n1.9.2.507.g779792a\n"},{"id":"240337","messageId":"20140430171105.GA8518@sigill.intra.peff.net","threadId":"36551","inReplyTo":"1398848287-77109-1-git-send-email-modocache@gmail.com","subject":"Re: [PATCH 1/2] strbuf: Use _rtrim and _ltrim in strbuf_trim","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-04-30T17:11:06Z","receivedAt":"2014-04-30T17:11:06Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Apr 30, 2014 at 05:58:06PM +0900, Brian Gesiak wrote:\n\n> strbuf_trim strips whitespace from the end, then the beginning of a\n> strbuf. Those operations are duplicated in strbuf_rtrim and\n> strbuf_ltrim.\n> \n> Replace strbuf_trim implementation with calls to strbuf_rtrim,\n> then strbuf_ltrim.\n\nThanks, this looks good. I wondered if perhaps doing them together\ninline might have been more efficient, but there really is no overlap in\nwhat they compute.\n\nThe documentation patch looks good to me, too.\n\n-Peff\n"}]}