summaryrefslogtreecommitdiff
path: root/mailinfo.c
Commit message (Collapse)AuthorAgeFilesLines
* hex.h: move some hex-related declarations from cache.hElijah Newren2023-02-231-1/+3
| | | | | | | | | | | | | | | | | | | | | hex.c contains code for hex-related functions, but for some reason these functions were declared in the catch-all cache.h. Move the function declarations into a hex.h header instead. This also allows us to remove includes of cache.h from a few C files. For now, we make cache.h include hex.h, so that it is easier to review the direct changes being made by this patch. In the next patch, we will remove that, and add the necessary direct '#include "hex.h"' in the hundreds of C files that need it. Note that reviewing the header changes in this commit might be simplified via git log --no-walk -p --color-moved $COMMIT -- '*.h'` In particular, it highlights the simple movement of code in .h files rather nicely. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* mailinfo -b: fix an out of bounds accessPhillip Wood2022-10-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To remove bracketed strings containing "PATCH" from the subject line cleanup_subject() scans the subject for the opening bracket using an offset from the beginning of the line. It then searches for the closing bracket with strchr(). To calculate the length of the bracketed string it unfortunately adds rather than subtracts the offset from the result of strchr(). This leads to an out of bounds access in memmem() when looking to see if the brackets contain "PATCH". We have tests that trigger this bug that were added in ae52d57f0b (t5100: add some more mailinfo tests, 2017-05-31). The commit message mentions that they are marked test_expect_failure as they trigger an assertion in strbuf_splice(). While it is reassuring that strbuf_splice() detects the problem and dies in retrospect that should perhaps have warranted a little more investigation. The bug was introduced by 17635fc900 (mailinfo: -b option keeps [bracketed] strings that is not a [PATCH] marker, 2009-07-15). I think the reason it has survived so long is that '-b' is not a popular option and without it the offset is always zero. This was found by the address sanitizer while I was cleaning up the test_todo idea in [1]. [1] https://lore.kernel.org/git/db558292-2783-3270-4824-43757822a389@gmail.com/ Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* tree-wide: apply equals-null.cocciJunio C Hamano2022-05-021-2/+2
| | | | Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'ar/mailinfo-memcmp-to-skip-prefix'Junio C Hamano2021-07-081-2/+2
|\ | | | | | | | | | | | | Code clean-up. * ar/mailinfo-memcmp-to-skip-prefix: mailinfo: use starts_with() when checking scissors
| * mailinfo: use starts_with() when checking scissorsAndrei Rybak2021-06-091-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Existing checks for scissors characters using memcmp(3) never read past the end of the line, because all substrings we are interested in are two characters long, and the outer loop guarantees we have at least one character. So at most we will look at the NUL. However, this is too subtle and may lead to bugs in code which copies this behavior without realizing substring length requirement. So use starts_with() instead, which will stop at NUL regardless of the length of the prefix. Remove extra pair of parentheses while we are here. Helped-by: Jeff King <peff@peff.net> Signed-off-by: Andrei Rybak <rybak.a.v@gmail.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'ef/mailinfo-short-name'Junio C Hamano2021-06-101-1/+1
|\ \ | | | | | | | | | | | | | | | | | | | | | We historically rejected a very short string as an author name while accepting a patch e-mail, which has been loosened. * ef/mailinfo-short-name: mailinfo: don't discard names under 3 characters
| * | mailinfo: don't discard names under 3 charactersedef2021-05-171-1/+1
| |/ | | | | | | | | | | | | | | | | | | | | I sometimes receive patches from people with short mononyms, and in my cultural environment these are not uncommon. To my dismay, git-am currently discards their names, and replaces them with their email addresses. Link: https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/ Signed-off-by: edef <edef@edef.eu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'dd/mailinfo-quoted-cr'Junio C Hamano2021-05-161-0/+39
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "git mailinfo" (hence "git am") learned the "--quoted-cr" option to control how lines ending with CRLF wrapped in base64 or qp are handled. * dd/mailinfo-quoted-cr: am: learn to process quoted lines that ends with CRLF mailinfo: allow stripping quoted CR without warning mailinfo: allow squelching quoted CRLF warning mailinfo: warn if CRLF found in decoded base64/QP email mailinfo: stop parsing options manually mailinfo: load default metainfo_charset lazily
| * | mailinfo: allow stripping quoted CR without warningĐoàn Trần Công Danh2021-05-101-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In previous changes, we've turned on warning for quoted CR in base64 or quoted-printable email messages. Some projects see those quoted CR a lot, they know that it happens most of the time, and they find it's desirable to always strip those CR. Those projects in question usually fall back to use other tools to handle patches when receive such patches. Let's help those projects handle those patches by stripping those excessive CR. Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | mailinfo: allow squelching quoted CRLF warningĐoàn Trần Công Danh2021-05-101-1/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In previous change, Git starts to warn for quoted CRLF in decoded base64/QP email. Despite those warnings are usually helpful, quoted CRLF could be part of some users' workflow. Let's give them an option to turn off the warning completely. Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | mailinfo: warn if CRLF found in decoded base64/QP emailĐoàn Trần Công Danh2021-05-101-0/+14
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When SMTP servers receive 8-bit email messages, possibly with only LF as line ending, some of them decide to change said LF to CRLF. Some mailing list softwares, when receive 8-bit email messages, decide to encode those messages in base64 or quoted-printable. If an email is transfered through above mail servers, then distributed by such mailing list softwares, the recipients will receive an email contains a patch mungled with CRLF encoded inside another encoding. Thus, such CR (in CRLF) couldn't be dropped by "mailsplit". Hence, the mailed patch couldn't be applied cleanly. Such accidents have been observed in the wild [1]. Instead of silently rejecting those messages, let's give our users some warnings if such CR (as part of CRLF) is found. [1]: https://nmbug.notmuchmail.org/nmweb/show/m2lf9ejegj.fsf%40guru.guru-group.fi Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | mailinfo: also free strbuf lists when clearing mailinfoAndrzej Hunt2021-04-281-11/+3
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | mailinfo.p_hdr_info/s_hdr_info are null-terminated lists of strbuf's, with entries pointing either to NULL or an allocated strbuf. Therefore we need to free those strbuf's (and not just the data they contain) whenever we're done with a given entry. (See handle_header() where those new strbufs are malloc'd.) Once we no longer need the list (and not just its entries) we can switch over to strbuf_list_free() instead of manually iterating over the list, which takes care of those additional details for us. We can only do this in clear_mailinfo() - in handle_commit_message() we are only clearing the array contents but want to reuse the array itself, hence we can't use strbuf_list_free() there. However, strbuf_list_free() cannot handle a NULL input, and the lists we are freeing might be NULL. Therefore we add a NULL check in strbuf_list_free() to make it safe to use with a NULL input (which is a pattern used by some of the other *_free() functions around git). Leak output from t0023: Direct leak of 72 byte(s) in 3 object(s) allocated from: #0 0x49a85d in malloc ../projects/compiler-rt/lib/asan/asan_malloc_linux.cpp:145:3 #1 0x9ac9f4 in do_xmalloc wrapper.c:41:8 #2 0x9ac9ca in xmalloc wrapper.c:62:9 #3 0x7f6cf7 in handle_header mailinfo.c:205:10 #4 0x7f5abf in check_header mailinfo.c:583:4 #5 0x7f5524 in mailinfo mailinfo.c:1197:3 #6 0x4dcc95 in parse_mail builtin/am.c:1167:6 #7 0x4d9070 in am_run builtin/am.c:1732:12 #8 0x4d5b7a in cmd_am builtin/am.c:2398:3 #9 0x4cd91d in run_builtin git.c:467:11 #10 0x4cb5f3 in handle_builtin git.c:719:3 #11 0x4ccf47 in run_argv git.c:808:4 #12 0x4caf49 in cmd_main git.c:939:19 #13 0x69e43e in main common-main.c:52:11 #14 0x7fc1fadfa349 in __libc_start_main (/lib64/libc.so.6+0x24349) SUMMARY: AddressSanitizer: 72 byte(s) leaked in 3 allocation(s). Signed-off-by: Andrzej Hunt <ajrhunt@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* mailinfo: disallow NUL character in mail's headerĐoàn Trần Công Danh2020-04-221-0/+5
| | | | | Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* mailinfo.c: avoid strlen on strings that can contains NULĐoàn Trần Công Danh2020-04-221-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | We're passing buffer from strbuf to reencode_string, which will call strlen(3) on that buffer, and discard the length of newly created buffer. Then, we compute the length of the return buffer to attach to strbuf. During this process, we introduce a discrimination between mail originally written in utf-8 and other encoding. * if the email was written in utf-8, we leave it as is. If there is a NUL character in that line, we complains loudly: error: a NUL byte in commit log message not allowed. * if the email was written in other encoding, we truncate the data as the NUL character in that line, then we used the truncated line for the metadata. We can do better by reusing all the available information, and call the underlying lower level function that will be called indirectly by reencode_string. By doing this, we will also postpone the NUL character processing to the commit step, which will complains about the faulty metadata. Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'rs/micro-cleanups'Junio C Hamano2020-03-021-2/+1
|\ | | | | | | | | | | | | | | Code cleanup. * rs/micro-cleanups: use strpbrk(3) to search for characters from a given set quote: use isalnum() to check for alphanumeric characters
| * use strpbrk(3) to search for characters from a given setRené Scharfe2020-02-241-2/+1
| | | | | | | | | | | | | | | | | | | | We can check if certain characters are present in a string by calling strchr(3) on each of them, or we can pass them all to a single strpbrk(3) call. The latter is shorter, less repetitive and slightly more efficient, so let's do that instead. Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | mailinfo: factor out some repeated header handlingJeff King2020-02-111-16/+23
| | | | | | | | | | | | | | | | We do the same thing for each header: match it, copy it to a strbuf, and decode it. Let's put that in a helper function to avoid repetition. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | mailinfo: be more liberal with header whitespaceJeff King2020-02-111-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | RFC822 and friends allow arbitrary whitespace after the colon of a header and before the values. I.e.: Subject:foo Subject: foo Subject: foo all have the subject "foo". But mailinfo requires exactly one space. This doesn't seem to be bothering anybody, but it is pickier than the standard specifies. And we can easily just soak up arbitrary whitespace there in our parser, so let's do so. Note that the test covers both too little and too much whitespace, but the "too much" case already works fine (because we later eat leading and trailing whitespace from the values). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | mailinfo: simplify parsing of header valuesJeff King2020-02-111-18/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Our code to parse header values first checks to see if a line starts with a header, and then manually skips past the matched string to find the value. We can do this all in one step by modeling after skip_prefix(), which returns a pointer into the string after the parsing. This lets us remove some repeated strings, and will also enable us to parse more flexibly in a future patch. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | mailinfo: treat header values as C stringsJeff King2020-02-111-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We read each header line into a strbuf, which means that we could in theory handle header values with embedded NUL bytes. But in practice, the values we parse out are passed to decode_header(), which uses strstr(), strchr(), etc. And we would not expect such bytes anyway; they are forbidden by RFC822, etc. and any non-ASCII characters should be encoded with RFC2047 encoding. So let's switch to using strbuf_addstr(), which saves us some length computations (and will enable further cleanups in this code). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | mailinfo: don't insert header prefix for handle_content_type()René Scharfe2020-02-101-1/+0
| | | | | | | | | | | | | | | | | | handle_content_type() only cares about the value after "Content-Type: "; there is no need to insert that string for it. Suggested-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | strbuf: add and use strbuf_insertstr()René Scharfe2020-02-101-2/+2
|/ | | | | | | | | | | | | | Add a function for inserting a C string into a strbuf. Use it throughout the source to get rid of magic string length constants and explicit strlen() calls. Like strbuf_addstr(), implement it as an inline function to avoid the implicit strlen() calls to cause runtime overhead. Helped-by: Taylor Blau <me@ttaylorr.com> Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* mailinfo: support format=flowedRené Scharfe2018-08-291-2/+62
| | | | | | | | | | | | | | | | | | Add best-effort support for patches sent using format=flowed (RFC 3676). Remove leading spaces ("unstuff"), remove soft line breaks (indicated by space + newline), but leave the signature separator (dash dash space newline) alone. Warn in git am when encountering a format=flowed patch, because any trailing spaces would most probably be lost, as the sending MUA is encouraged to remove them when preparing the email. Provide a test patch formatted by Mozilla Thunderbird 60 using its default configuration. It reuses the contents of the file mailinfo.c before and after this patch. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Replace all die("BUG: ...") calls by BUG() onesJohannes Schindelin2018-05-061-1/+1
| | | | | | | | | | | | | | | | | | | | | In d8193743e08 (usage.c: add BUG() function, 2017-05-12), a new macro was introduced to use for reporting bugs instead of die(). It was then subsequently used to convert one single caller in 588a538ae55 (setup_git_env: convert die("BUG") to BUG(), 2017-05-12). The cover letter of the patch series containing this patch (cf 20170513032414.mfrwabt4hovujde2@sigill.intra.peff.net) is not terribly clear why only one call site was converted, or what the plan is for other, similar calls to die() to report bugs. Let's just convert all remaining ones in one fell swoop. This trick was performed by this invocation: sed -i 's/die("BUG: /BUG("/g' $(git grep -l 'die("BUG' \*.c) Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'jc/mailinfo-cleanup-fix'Junio C Hamano2018-02-131-4/+6
|\ | | | | | | | | | | | | Corner case bugfix. * jc/mailinfo-cleanup-fix: mailinfo: avoid segfault when can't open files
| * mailinfo: avoid segfault when can't open filesjc/mailinfo-cleanup-fixJuan F. Codagnone2018-01-241-4/+6
| | | | | | | | | | | | | | | | | | | | | | If <msg> or <patch> files can't be opened, then mailinfo() returns an error before it even initializes mi->p_hdr_data or mi->s_hdr_data. When cmd_mailinfo() then calls clear_mailinfo(), we dereference the NULL pointers trying to free their contents. Signed-off-by: Juan F. Codagnone <jcodagnone@gmail.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'rs/mailinfo-qp-decode-fix'Junio C Hamano2017-09-281-3/+8
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | "git mailinfo" was loose in decoding quoted printable and produced garbage when the two letters after the equal sign are not hexadecimal. This has been fixed. * rs/mailinfo-qp-decode-fix: mailinfo: don't decode invalid =XY quoted-printable sequences
| * | mailinfo: don't decode invalid =XY quoted-printable sequencesrs/mailinfo-qp-decode-fixRené Scharfe2017-09-241-3/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Decode =XY in quoted-printable segments only if X and Y are hexadecimal digits, otherwise just copy them. That's at least better than interpreting negative results from hexval() as a character. Reported-by: Jeff King <peff@peff.net> Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | consistently use "fallthrough" comments in switchesjk/fallthroughJeff King2017-09-221-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Gcc 7 adds -Wimplicit-fallthrough, which can warn when a switch case falls through to the next case. The general idea is that the compiler can't tell if this was intentional or not, so you should annotate any intentional fall-throughs as such, leaving it to complain about any unannotated ones. There's a GNU __attribute__ which can be used for annotation, but of course we'd have to #ifdef it away on non-gcc compilers. Gcc will also recognize specially-formatted comments, which matches our current practice. Let's extend that practice to all of the unannotated sites (which I did look over and verify that they were behaving as intended). Ideally in each case we'd actually give some reasons in the comment about why we're falling through, or what we're falling through to. And gcc does support that with -Wimplicit-fallthrough=2, which relaxes the comment pattern matching to anything that contains "fallthrough" (or a variety of spelling variants). However, this isn't the default for -Wimplicit-fallthrough, nor for -Wextra. In the name of simplicity, it's probably better for us to support the default level, which requires "fallthrough" to be the only thing in the comment (modulo some window dressing like "else" and some punctuation; see the gcc manual for the complete set of patterns). This patch suppresses all warnings due to -Wimplicit-fallthrough. We might eventually want to add that to the DEVELOPER Makefile knob, but we should probably wait until gcc 7 is more widely adopted (since earlier versions will complain about the unknown warning type). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | mailinfo: release strbuf on error return in handle_boundary()Rene Scharfe2017-09-071-0/+1
| | | | | | | | | | | | | | | Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | mailinfo: release strbuf after use in handle_from()Rene Scharfe2017-09-071-5/+4
| | | | | | | | | | | | | | | | | | | | | Clean up at the end and jump there instead of returning early. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Spelling fixesvs/typofixesVille Skyttä2017-06-271-8/+8
| | | | | | | | | | | | | | | Signed-off-by: Ville Skyttä <ville.skytta@iki.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Merge branch 'ab/free-and-null'Junio C Hamano2017-06-241-2/+1
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A common pattern to free a piece of memory and assign NULL to the pointer that used to point at it has been replaced with a new FREE_AND_NULL() macro. * ab/free-and-null: *.[ch] refactoring: make use of the FREE_AND_NULL() macro coccinelle: make use of the "expression" FREE_AND_NULL() rule coccinelle: add a rule to make "expression" code use FREE_AND_NULL() coccinelle: make use of the "type" FREE_AND_NULL() rule coccinelle: add a rule to make "type" code use FREE_AND_NULL() git-compat-util: add a FREE_AND_NULL() wrapper around free(ptr); ptr = NULL
| * | | coccinelle: make use of the "type" FREE_AND_NULL() ruleÆvar Arnfjörð Bjarmason2017-06-161-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Apply the result of the just-added coccinelle rule. This manually excludes a few occurrences, mostly things that resulted in many FREE_AND_NULL() on one line, that'll be manually fixed in a subsequent change. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | Merge branch 'bw/config-h'Junio C Hamano2017-06-241-0/+1
|\ \ \ \ | |/ / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix configuration codepath to pay proper attention to commondir that is used in multi-worktree situation, and isolate config API into its own header file. * bw/config-h: config: don't implicitly use gitdir or commondir config: respect commondir setup: teach discover_git_directory to respect the commondir config: don't include config.h by default config: remove git_config_iter config: create config.h
| * | | config: don't include config.h by defaultBrandon Williams2017-06-151-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Stop including config.h by default in cache.h. Instead only include config.h in those files which require use of the config system. Signed-off-by: Brandon Williams <bmwill@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | mailinfo & mailsplit: check for EOF while parsingJohannes Schindelin2017-05-081-1/+8
|/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While POSIX states that it is okay to pass EOF to isspace() (and it seems to be implied that EOF should *not* be treated as whitespace), and also to pass EOF to ungetc() (which seems to be intended to fail without buffering the character), it is much better to handle these cases explicitly. Not only does it reduce head-scratching (and helps static analysis avoid reporting false positives), it also lets us handle files containing nothing but whitespace by erroring out. Reported via Coverity. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Merge branch 'lt/mailinfo-in-body-header-continuation'Junio C Hamano2017-04-191-1/+6
|\ \ \ | |_|/ |/| | | | | | | | | | | | | | | | | | | | | | | If a patch e-mail had its first paragraph after an in-body header indented (even after a blank line after the in-body header line), the indented line was mistook as a continuation of the in-body header. This has been fixed. * lt/mailinfo-in-body-header-continuation: mailinfo: fix in-body header continuations
| * | mailinfo: fix in-body header continuationslt/mailinfo-in-body-header-continuationLinus Torvalds2017-04-111-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | An empty line should stop any pending in-body headers, and start the actual body parsing. This also modifies the original test for the in-body headers to actually have a real commit body that starts with spaces, and changes the test to check that the long line matches _exactly_, and doesn't get extra data from the body. Fixes:6b4b013f1884 ("mailinfo: handle in-body header continuations") Cc: Jonathan Tan <jonathantanmy@google.com> Cc: Jeff King <peff@peff.net> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Merge branch 'jt/mailinfo-fold-in-body-headers'Junio C Hamano2016-12-211-1/+2
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | Fix for NDEBUG builds. * jt/mailinfo-fold-in-body-headers: mailinfo.c: move side-effects outside of assert
| * | | mailinfo.c: move side-effects outside of assertjt/mailinfo-fold-in-body-headersKyle J. McKay2016-12-201-1/+2
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since 6b4b013f18 (mailinfo: handle in-body header continuations, 2016-09-20, v2.11.0) mailinfo.c has contained new code with an assert of the form: assert(call_a_function(...)) The function in question, check_header, has side effects. This means that when NDEBUG is defined during a release build the function call is omitted entirely, the side effects do not take place and tests (fortunately) start failing. Since the only time that mi->inbody_header_accum is appended to is in check_inbody_header, and appending onto a blank mi->inbody_header_accum always happens when is_inbody_header is true, this guarantees a prefix that causes check_header to always return true. Therefore replace the assert with an if !check_header + DIE combination to reflect this. Helped-by: Jonathan Tan <jonathantanmy@google.com> Helped-by: Jeff King <peff@peff.net> Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Kyle J. McKay <mackyle@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Merge branch 'kd/mailinfo-quoted-string'Junio C Hamano2016-10-031-0/+82
|\ \ \ | |/ / |/| / | |/ | | | | | | | | | | | | An author name, that spelled a backslash-quoted double quote in the human readable part "My \"double quoted\" name", was not unquoted correctly while applying a patch from a piece of e-mail. * kd/mailinfo-quoted-string: mailinfo: unescape quoted-pair in header fields t5100-mailinfo: replace common path prefix with variable
| * mailinfo: unescape quoted-pair in header fieldskd/mailinfo-quoted-stringKevin Daudt2016-09-281-0/+82
| | | | | | | | | | | | | | | | | | | | | | | | | | | | rfc2822 has provisions for quoted strings in structured header fields, but also allows for escaping these with so-called quoted-pairs. The only thing git currently does is removing exterior quotes, but quotes within are left alone. Remove exterior quotes and remove escape characters so that they don't show up in the author field. Signed-off-by: Kevin Daudt <me@ikke.info> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * Merge branch 'rs/mailinfo-lib' into maintJunio C Hamano2016-09-081-7/+2
| |\ | | | | | | | | | | | | | | | | | | Small code clean-up. * rs/mailinfo-lib: mailinfo: recycle strbuf in check_header()
* | | mailinfo: handle in-body header continuationsJonathan Tan2016-09-211-1/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Mailinfo currently handles multi-line headers, but it does not handle multi-line in-body headers. Teach it to handle such headers, for example, for this input: From: author <author@example.com> Date: Fri, 9 Jun 2006 00:44:16 -0700 Subject: a very long broken line Subject: another very long broken line interpret the in-body subject to be "another very long broken line" instead of "another very long". An existing test (t/t5100/msg0015) has an indented line immediately after an in-body header - it has been modified to reflect the new functionality. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | mailinfo: make is_scissors_line take plain char *Jonathan Tan2016-09-191-17/+18
| | | | | | | | | | | | | | | | | | | | | | | | The is_scissors_line takes a struct strbuf * when a char * would suffice. Make it take char *. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | mailinfo: separate in-body header processingJonathan Tan2016-09-191-16/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The check_header function contains logic specific to in-body headers, although it is invoked during both the processing of actual headers and in-body headers. Separate out the in-body header part into its own function. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Merge branch 'rs/mailinfo-lib'Junio C Hamano2016-08-171-7/+2
|\ \ \ | |/ / |/| / | |/ | | | | | | Small code clean-up. * rs/mailinfo-lib: mailinfo: recycle strbuf in check_header()
| * mailinfo: recycle strbuf in check_header()rs/mailinfo-libRené Scharfe2016-08-131-7/+2
| | | | | | | | | | | | | | | | | | | | handle_message_id() duplicates the contents of the strbuf that is passed to it. Its only caller proceeds to release the strbuf immediately after that. Reuse it instead and make that change of object ownership more obvious by inlining this short function. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | strbuf: introduce strbuf_getline_{lf,nul}()Junio C Hamano2016-01-151-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The strbuf_getline() interface allows a byte other than LF or NUL as the line terminator, but this is only because I wrote these codepaths anticipating that there might be a value other than NUL and LF that could be useful when I introduced line_termination long time ago. No useful caller that uses other value has emerged. By now, it is clear that the interface is overly broad without a good reason. Many codepaths have hardcoded preference to read either LF terminated or NUL terminated records from their input, and then call strbuf_getline() with LF or NUL as the third parameter. This step introduces two thin wrappers around strbuf_getline(), namely, strbuf_getline_lf() and strbuf_getline_nul(), and mechanically rewrites these call sites to call either one of them. The changes contained in this patch are: * introduction of these two functions in strbuf.[ch] * mechanical conversion of all callers to strbuf_getline() with either '\n' or '\0' as the third parameter to instead call the respective thin wrapper. After this step, output from "git grep 'strbuf_getline('" would become a lot smaller. An interim goal of this series is to make this an empty set, so that we can have strbuf_getline_crlf() take over the shorter name strbuf_getline(). Signed-off-by: Junio C Hamano <gitster@pobox.com>
View Lorry Controller Status