aboutsummaryrefslogtreecommitdiffstats
path: root/tools/perf/util/trace-event-scripting.c
diff options
context:
space:
mode:
authorJaehun Gou <p22gone@gmail.com>2025-10-14 22:01:46 +0900
committerNamjae Jeon <linkinjeon@kernel.org>2025-10-15 14:37:21 +0900
commit82ebecdc74ff555daf70b811d854b1f32a296bea (patch)
tree977beda498b5701baad37548abffef3edecfb900 /tools/perf/util/trace-event-scripting.c
parentMerge tag 'nfsd-6.18-1' of git://git.kernel.org/pub/scm/linux/kernel/git/cel/... (diff)
downloadlinux-82ebecdc74ff555daf70b811d854b1f32a296bea.tar.gz
linux-82ebecdc74ff555daf70b811d854b1f32a296bea.zip
exfat: fix improper check of dentry.stream.valid_size
We found an infinite loop bug in the exFAT file system that can lead to a Denial-of-Service (DoS) condition. When a dentry in an exFAT filesystem is malformed, the following system calls — SYS_openat, SYS_ftruncate, and SYS_pwrite64 — can cause the kernel to hang. Root cause analysis shows that the size validation code in exfat_find() does not check whether dentry.stream.valid_size is negative. As a result, the system calls mentioned above can succeed and eventually trigger the DoS issue. This patch adds a check for negative dentry.stream.valid_size to prevent this vulnerability. Co-developed-by: Seunghun Han <kkamagui@gmail.com> Signed-off-by: Seunghun Han <kkamagui@gmail.com> Co-developed-by: Jihoon Kwon <jimmyxyz010315@gmail.com> Signed-off-by: Jihoon Kwon <jimmyxyz010315@gmail.com> Signed-off-by: Jaehun Gou <p22gone@gmail.com> Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
Diffstat (limited to 'tools/perf/util/trace-event-scripting.c')
0 files changed, 0 insertions, 0 deletions
generated by cgit v1.2.3 (git 2.39.1) at 2025-12-21 00:06:46 +0000
08) uses find_basename() to calculate the length of directory part in prepare_attr_stack. This function expects the directory without the trailing slash (as "origin" field in match_attr struct is without the trailing slash). find_basename() includes the trailing slash and confuses push/pop algorithm. Consider path = "abc/def" and the push down code: while (1) { len = strlen(attr_stack->origin); if (dirlen <= len) break; cp = memchr(path + len + 1, '/', dirlen - len - 1); if (!cp) cp = path + dirlen; dirlen is 4, not 3, without this patch. So when attr_stack->origin is "abc", it'll miss the exit condition because 4 <= 3 is wrong. It'll then try to push "abc/" down the attr stack (because "cp" would be NULL). So we have both "abc" and "abc/" in the stack. Next time when "abc/ghi" is checked, "abc/" is popped out because of the off-by-one dirlen, only to be pushed back in again by the above code. This repeats for all files in the same directory. Which means at least one failed open syscall per file, or more if .gitattributes exists. This is the perf result with 10 runs on git.git: Test 94bc671^ 94bc671 HEAD ---------------------------------------------------------------------------------------------------------- 7810.1: grep worktree, cheap regex 0.02(0.01+0.04) 0.05(0.03+0.05) +150.0% 0.02(0.01+0.04) +0.0% 7810.2: grep worktree, expensive regex 0.25(0.94+0.01) 0.26(0.94+0.02) +4.0% 0.25(0.93+0.02) +0.0% 7810.3: grep --cached, cheap regex 0.11(0.10+0.00) 0.12(0.10+0.02) +9.1% 0.10(0.10+0.00) -9.1% 7810.4: grep --cached, expensive regex 0.61(0.60+0.01) 0.62(0.61+0.01) +1.6% 0.61(0.60+0.00) +0.0% Reported-by: Ross Lagerwall <rosslagerwall@gmail.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2013-01-14rebase --preserve-merges: keep all merge commits including empty onesPhil Hord1-1/+6 Since 90e1818f9a (git-rebase: add keep_empty flag, 2012-04-20) 'git rebase --preserve-merges' fails to preserve empty merge commits unless --keep-empty is also specified. Merge commits should be preserved in order to preserve the structure of the rebased graph, even if the merge commit does not introduce changes to the parent. Teach rebase not to drop merge commits only because they are empty. A special case which is not handled by this change is for a merge commit whose parents are now the same commit because all the previous different parents have been dropped as a result of this rebase or some previous operation. Signed-off-by: Phil Hord <hordp@cisco.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2013-01-14Git 1.8.1.1v1.8.1.1Junio C Hamano3-2/+54 Signed-off-by: Junio C Hamano <gitster@pobox.com> 2013-01-11git-completion.bash: silence "not a valid object" errorsDylan Smith1-1/+1 Trying to complete the command git show master:./file would cause a "Not a valid object name" error to be output on standard error. Silence the error so it won't appear on the command line. Signed-off-by: Dylan Smith <dylan.ah.smith@gmail.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2013-01-10contrib/vim: simplify instructions for old vim supportJonathan Nieder1-13/+3 Rely on the upstream filetype.vim instead of duplicating its rules in git's instructions for syntax highlighting support on pre-7.2 vim versions. The result is a shorter contrib/vim/README. More importantly, it lets us punt on maintenance of the autocmd rules. So now when we fix the upstream gitsendemail rule in light of commit eed6ca7, new git users stuck on old vim reading contrib/vim/README can automagically get the fix without any further changes needed to git. Once the world has moved on to vim 7.2+ completely, we can get rid of these instructions, but for now if they are this simple it's effortless to keep them. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2013-01-10Prepare for 1.8.1.1Junio C Hamano2-1/+37 2013-01-10Makefile: detect when PYTHON_PATH changesChristian Couder2-2/+15 When make is run, the python scripts are created from *.py files that are changed to use the python given by PYTHON_PATH. And PYTHON_PATH is set by default to /usr/bin/python on Linux. However, next time make is run with a different value in PYTHON_PATH, we failed to regenerate these scripts. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Acked-by: Pete Wyckoff <pw@padd.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2013-01-10git-commit-tree(1): correct description of defaultsPeter Eisentraut1-2/+2 The old phrasing indicated that the EMAIL environment variable takes precedence over the user.email configuration setting, but it is the other way around. Signed-off-by: Peter Eisentraut <peter@eisentraut.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2013-01-09git-fast-import(1): reorganise optionsJohn Keeping1-39/+47 The options in git-fast-import(1) are not currently arranged in a logical order, which has caused the '--done' options to be documented twice (commit 3266de10). Rearrange them into logical groups under subheadings. Suggested-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2013-01-09git-fast-import(1): combine documentation of --[no-]relative-marksJohn Keeping1-6/+4 The descriptions of '--relative-marks' and '--no-relative-marks' make more sense when read together instead of as two independent options. Combine them into a single description block. Signed-off-by: John Keeping <john@keeping.me.uk> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2013-01-09git-shortlog(1): document behaviour of zero-width wrapJohn Keeping1-0/+3 Commit 00d3947 (Teach --wrap to only indent without wrapping) added special behaviour for a width of zero in the '-w' argument to 'git-shortlog' but this was not documented. Fix this. Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2013-01-08git-fast-import(1): remove duplicate '--done' optionJohn Keeping1-5/+2 The '--done' option to git-fast-import is documented twice in its manual page. Combine the best bits of each description, keeping the location of the instance that was added first. Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2013-01-08t1402: work around shell quoting issue on NetBSDRené Scharfe1-2/+4 The test fails for me on NetBSD 6.0.1 and reports: ok 1 - ref name '' is invalid ok 2 - ref name '/' is invalid ok 3 - ref name '/' is invalid with options --allow-onelevel ok 4 - ref name '/' is invalid with options --normalize error: bug in the test script: not 2 or 3 parameters to test-expect-success The alleged bug is in this line: invalid_ref NOT_MINGW '/' '--allow-onelevel --normalize' invalid_ref() constructs a test case description using its last argument, but the shell seems to split it up into two pieces if it contains a space. Minimal test case: # on NetBSD with /bin/sh $ a() { echo $#-$1-$2; } $ t="x"; a "${t:+$t}" 1-x- $ t="x y"; a "${t:+$t}" 2-x-y $ t="x y"; a "${t:+x y}" 1-x y- # and with bash $ t="x y"; a "${t:+$t}" 1-x y- $ t="x y"; a "${t:+x y}" 1-x y- This may be a bug in the shell, but here's a simple workaround: Construct the description string first and store it in a variable, and then use that to call test_expect_success(). Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2013-01-08remote-hg: Fix biridectionality -> bidirectionality typosW. Trevor King2-2/+2 Signed-off-by: W. Trevor King <wking@tremily.us> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2013-01-07Prevent space after directories in tcsh completionMarc Khouzam1-12/+21 If git-completion.bash returns a single directory as a completion, tcsh will automatically add a space after it, which is not what the user wants. This commit prevents tcsh from doing this. Also, a check is added to make sure the tcsh version used is recent enough to allow completion to work as expected. Signed-off-by: Marc Khouzam <marc.khouzam@ericsson.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2013-01-07status: always report ignored tracked directoriesAntoine Pelisse1-6/+3 When enumerating paths that are ignored, paths the index knows about are not included in the result. The "index knows about" check is done by consulting the name hash, not the actual contents of the index: - When core.ignorecase is false, directory names are not in the name hash, and ignored ones are shown as ignored (directories can never be tracked anyway). - When core.ignorecase is true, however, the name hash keeps track of the names of directories, in order to detect additions of the paths under different cases. This causes ignored directories to be mistakenly excluded when enumerating ignored paths. Stop excluding directories that are in the name hash when looking for ignored files in dir_add_name(); the names that are actually in the index are excluded much earlier in the callchain in treat_file(), so this fix will not make them mistakenly identified as ignored. Signed-off-by: Antoine Pelisse <apelisse@gmail.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2013-01-07t5003: check if unzip supports symlinksRené Scharfe2-7/+19 Only add a symlink to the repository if both the filesystem and unzip support symlinks. To check the latter, add a ZIP file containing a symlink, created like this with InfoZIP zip 3.0: $ echo sample text >textfile $ ln -s textfile symlink $ zip -y infozip-symlinks.zip textfile symlink If we can extract it successfully, we add a symlink to the test repository for git archive --format=zip, or otherwise skip that step. Users can see the skipped test and perhaps run it again with a different unzip version. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2013-01-07t5000, t5003: move ZIP tests into their own scriptRené Scharfe2-69/+119 This makes ZIP specific tweaks easier. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2013-01-07t0024, t5000: use test_lazy_prereq for UNZIPRené Scharfe2-14/+10 This change makes the code smaller and we can put it at the top of the script, its rightful place as setup code. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2013-01-06git-send-email: treat field names as case-insensitivelyNickolai Zeldovich1-5/+5 Field names like To:, Cc:, etc. are case-insensitive; use a case-insensitive regexp to match them as such. Previously, git-send-email would fail to pick-up the addresses when in-body "fake" headers with different cases (e.g. lowercase "cc:") are manually inserted to the messages it was asked to send, even though the text will still show them. Signed-off-by: Nickolai Zeldovich <nickolai@csail.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2013-01-06t0024, t5000: clear variable UNZIP, use GIT_UNZIP insteadRené Scharfe3-8/+10 InfoZIP's unzip takes default parameters from the environment variable UNZIP. Unset it in the test library and use GIT_UNZIP for specifying alternate versions of the unzip command instead. t0024 wasn't even using variable for the actual extraction. t5000 was, but when setting it to InfoZIP's unzip it would try to extract from itself (because it treats the contents of $UNZIP as parameters), which failed of course. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2013-01-06Makefile: add comment on CYGWIN_V15_WIN32APIMark Levedahl1-0/+4 There is no documented, reliable, and future-proof method to determine the installed w32api version on Cygwin. There are many things that can be done that will work frequently, except when they won't. The only sane thing is to follow the guidance of the Cygwin developers: the only supported configuration is that which the current setup.exe produces, and in the case of problems, if the installation is not up to date then updating is the first required action. Signed-off-by: Mark Levedahl <mlevedahl@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2013-01-06api-allocation-growing.txt: encourage better variable namingAdam Spiers1-6/+8 The documentation for the ALLOC_GROW API implicitly encouraged developers to use "ary" as the variable name for the array which is dynamically grown. However "ary" is an unusual abbreviation hardly used anywhere else in the source tree, and it is also better to name variables based on their contents not on their type. Signed-off-by: Adam Spiers <git@adamspiers.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2013-01-06archive-zip: write uncompressed size into header even with streamingRené Scharfe1-5/+2 We record the uncompressed and compressed sizes and the CRC of streamed files as zero in the local header of the file. The actual values are recorded in an extra data descriptor after the file content, and in the usual ZIP directory entry at the end of the archive. While we know the compressed size and the CRC only after we processed the contents, we actually know the uncompressed size right from the start. And for files that we store uncompressed we also already know their final size. Do it like InfoZIP's zip and recored the known values, even though they can be reconstructed using the ZIP directory and the data descriptors alone. InfoZIP's unzip worked fine before, but NetBSD's version actually depends on these fields. The uncompressed size is already set by sha1_object_info(). We just need to initialize the compressed size to zero or the uncompressed size depending on the compression method (0 means storing). The CRC was propertly initialized already. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2013-01-06docs: manpage XML depends on asciidoc.confJonathan Nieder1-5/+3 When building manual pages, the source text is transformed to XML with AsciiDoc before the man pages are generated from the XML with xmlto. Fix the dependencies in the Makefile so that the XML files are rebuilt when asciidoc.conf changes and not just the manual pages from unchanged XML, and move the dependencies from a recipeless rule to the rules with commands that use asciidoc.conf to make the dependencies easier to understand and maintain. Reported-by: John Keeping <john@keeping.me.uk> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Tested-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2013-01-06run-command: encode signal death as a positive integerJeff King4-7/+5 When a sub-command dies due to a signal, we encode the signal number into the numeric exit status as "signal - 128". This is easy to identify (versus a regular positive error code), and when cast to an unsigned integer (e.g., by feeding it to exit), matches what a POSIX shell would return when reporting a signal death in $? or through its own exit code. So we have a negative value inside the code, but once it passes across an exit() barrier, it looks positive (and any code we receive from a sub-shell will have the positive form). E.g., death by SIGPIPE (signal 13) will look like -115 to us in inside git, but will end up as 141 when we call exit() with it. And a program killed by SIGPIPE but run via the shell will come to us with an exit code of 141. Unfortunately, this means that when the "use_shell" option is set, we need to be on the lookout for _both_ forms. We might or might not have actually invoked the shell (because we optimize out some useless shell calls). If we didn't invoke the shell, we will will see the sub-process's signal death directly, and run-command converts it into a negative value. But if we did invoke the shell, we will see the shell's 128+signal exit status. To be thorough, we would need to check both, or cast the value to an unsigned char (after checking that it is not -1, which is a magic error value). Fortunately, most callsites do not care at all whether the exit was from a code or from a signal; they merely check for a non-zero status, and sometimes propagate the error via exit(). But for the callers that do care, we can make life slightly easier by just using the consistent positive form. This actually fixes two minor bugs: 1. In launch_editor, we check whether the editor died from SIGINT or SIGQUIT. But we checked only the negative form, meaning that we would fail to notice a signal death exit code which was propagated through the shell. 2. In handle_alias, we assume that a negative return value from run_command means that errno tells us something interesting (like a fork failure, or ENOENT). Otherwise, we simply propagate the exit code. Negative signal death codes confuse us, and we print a useless "unable to run alias 'foo': Success" message. By encoding signal deaths using the positive form, the existing code just propagates it as it would a normal non-zero exit code. The downside is that callers of run_command can no longer differentiate between a signal received directly by the sub-process, and one propagated. However, no caller currently cares, and since we already optimize out some calls to the shell under the hood, that distinction is not something that should be relied upon by callers. Fix the same logic in t/test-terminal.perl for consistency [jc: raised by Jonathan in the discussion]. Signed-off-by: Jeff King <peff@peff.net> Acked-by: Johannes Sixt <j6t@kdbg.org> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2013-01-05archive-tar: split long paths more carefullyRené Scharfe1-0/+2 The name field of a tar header has a size of 100 characters. This limit was extended long ago in a backward compatible way by providing the additional prefix field, which can hold 155 additional characters. The actual path is constructed at extraction time by concatenating the prefix field, a slash and the name field. get_path_prefix() is used to determine which slash in the path is used as the cutting point and thus which part of it is placed into the field prefix and which into the field name. It tries to cram as much into the prefix field as possible. (And only if we can't fit a path into the provided 255 characters we use a pax extended header to store it.) If a path is longer than 100 but shorter than 156 characters and ends with a slash (i.e. is for a directory) then get_path_prefix() puts the whole path in the prefix field and leaves the name field empty. GNU tar reconstructs the path without complaint, but the tar included with NetBSD 6 does not: It reports the header to be invalid. For compatibility with this version of tar, make sure to never leave the name field empty. In order to do that, trim the trailing slash from the part considered as possible prefix, if it exists -- that way the last path component (or more, but not less) will end up in the name field. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2013-01-05fix compilation with NO_PTHREADSJeff King1-1/+1 Commit 1327452 cleaned up an unused parameter from wait_or_whine, but forgot to update a caller that is inside "#ifdef NO_PTHREADS". Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2013-01-05clone: support atomic operation with --separate-git-dirJens Lehmann2-2/+14 Since b57fb80a7d (init, clone: support --separate-git-dir for .git file) git clone supports the --separate-git-dir option to create the git dir outside the work tree. But when that option is used, the git dir won't be deleted in case the clone fails like it would be without this option. This makes clone lose its atomicity as in case of a failure a partly set up git dir is left behind. A real world example where this leads to problems is when "git submodule update" fails to clone a submodule and later calls to "git submodule update" stumble over the partially set up git dir and try to revive the submodule from there, which then fails with a not very user friendly error message. Fix that by updating the junk_git_dir variable (used to remember if and what git dir should be removed in case of failure) to the new value given with the --seperate-git-dir option. Also add a test for this to t5600 (and while at it fix the former last test to not cd into a directory to test for its existence but use "test -d" instead). Reported-by: Manlio Perillo <manlio.perillo@gmail.com> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2013-01-03merge: Honor prepare-commit-msg return codeAntoine Pelisse2-2/+17 65969d4 (merge: honor prepare-commit-msg hook, 2011-02-14) tried to make "git commit" and "git merge" consistent, because a merge that required user assistance has to be concluded with "git commit", but back then only "git commit" triggered prepare-commit-msg hook. When it added a call to run the prepare-commit-msg hook, however, it forgot to check the exit code from the hook like "git commit" does, and ended up replacing one inconsistency with another. When prepare-commit-msg hook that is run from "git merge" exits with a non-zero status, abort the commit. Signed-off-by: Antoine Pelisse <apelisse@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2013-01-03tests: turn on test-lint by defaultJeff King1-0/+1 The test Makefile knows about a few "lint" checks for common errors. However, they are not enabled as part of "make test" by default, which means that many people do not bother running them. Since they are both quick to run and accurate (i.e., no false positives), there should be no harm in turning them on and helping submitters catch errors earlier. We could just set: TEST_LINT = test-lint to enable all tests. But that would be unnecessarily annoying later on if we add slower or less accurate tests that should not be part of the default. Instead, we name the tests individually. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2013-01-02build: do not automatically reconfigure unless configure.ac changedJonathan Nieder1-2/+8 Starting with v1.7.12-rc0~4^2 (build: reconfigure automatically if configure.ac changes, 2012-07-19), "config.status --recheck" is automatically run every time the "configure" script changes. In particular, that means the configuration procedure repeats whenever the version number changes (since the configure script changes to support "./configure --version" and "./configure --help"), making bisecting painfully slow. The intent was to make the reconfiguration process only trigger for changes to configure.ac's logic. Tweak the Makefile rule to match that intent by depending on configure.ac instead of configure. Reported-by: Martin von Zweigbergk <martinvonz@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Reviewed-by: Jeff King <peff@peff.net> Reviewed-by: Stefano Lattarini <stefano.lattarini@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2013-01-02SubmittingPatches: give list and maintainer addressesJunio C Hamano1-2/+6 We told readers to "send it to the list" (or the maintainer) without telling what addresses are to be used. Correct this. Signed-off-by: Junio C Hamano <gitster@pobox.com> 2013-01-02SubmittingPatches: remove overlong checklistJunio C Hamano1-76/+61 The section is no longer a concise checklist. It also talks about things that are not covered in the "Long version" text, which means people need to read both, covering more or less the same thing in different phrasing. Fold the details into the main text and remove the section. Signed-off-by: Junio C Hamano <gitster@pobox.com> 2013-01-01t9020: which is not portableTorsten Bögershausen1-2/+2 Use type instead Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2013-01-01t9810: Do not use sed -iTorsten Bögershausen1-10/+14 sed -i is not portable on all systems. Use sed with different input and output files. Utilize a tmp file whenever needed. Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2013-01-01gitweb: fix error in sanitize when highlight is enabledOrgad Shaneh1-1/+1 $1 becomes undef by internal regex, since it has no capture groups. Match against accpetable control characters using index() instead of a regex. Signed-off-by: Orgad Shaneh <orgads@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>