Commit Graph

9 Commits

Author SHA1 Message Date
Matthew DeVore
dcbaa0b361 t/*: fix ordering of expected/observed arguments
Fix various places where the ordering was obviously wrong, meaning it
was easy to find with grep.

Signed-off-by: Matthew DeVore <matvore@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-07 08:51:18 +09:00
Tanay Abhra
c8466645ed make config --add behave correctly for empty and NULL values
Currently if we have a config file like,
[foo]
        baz
        bar =

and we try something like, "git config --add foo.baz roll", Git will
segfault. Moreover, for "git config --add foo.bar roll", it will
overwrite the original value instead of appending after the existing
empty value.

The problem lies with the regexp used for simulating --add in
`git_config_set_multivar_in_file()`, "^$", which in ideal case should
not match with any string but is true for empty strings. Instead use a
regexp like "a^" which can not be true for any string, empty or not.

For removing the segfault add a check for NULL values in `matches()` in
config.c.

Signed-off-by: Tanay Abhra <tanayabh@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-08-18 10:45:59 -07:00
Thomas Rast
83786fa412 config: arbitrary number of matches for --unset and --replace-all
git-config used a static match array to hold the matches we want to
unset/replace when using --unset or --replace-all.  Use a
variable-sized array instead.

This in particular fixes the symptoms git-svn had when storing large
numbers of svn-remote.*.added-placeholder entries in the config file.

While the tests are rather more paranoid than just --unset and
--replace-all, the other operations already worked.  Indeed git-svn's
usage only breaks the first time *after* creating so many entries,
when it wants to unset and re-add them all.

Reported-by: Jess Hottenstein <jess.hottenstein@gmail.com>
Signed-off-by: Thomas Rast <tr@thomasrast.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-06 11:48:47 -08:00
Erik Faye-Lund
e96c19c50f config: support values longer than 1023 bytes
parse_value in config.c has a static buffer of 1024 bytes that it
parse the value into. This can sometimes be a problem when a
config file contains very long values.

It's particularly amusing that git-config already is able to write
such files, so it should probably be able to read them as well.

Fix this by using a strbuf instead of a fixed-size buffer.

Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-11 14:10:06 -07:00
Thomas Jarosch
e0b3cc0dff Fix buffer overflow in config parser
When interpreting a config value, the config parser reads in 1+ space
character(s) and puts -one- space character in the buffer as soon as
the first non-space character is encountered (if not inside quotes).

Unfortunately the buffer size check lacks the extra space character
which gets inserted at the next non-space character, resulting in
a crash with a specially crafted config entry.

The unit test now uses Java to compile a platform independent
.NET framework to output the test string in C# :o)

    Read: Thanks to Johannes Sixt for the correct printf call
    which replaces the perl invocation.

Signed-off-by: Thomas Jarosch <thomas.jarosch@intra2net.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-17 20:59:01 -07:00
Nanako Shiraishi
0cb0e143ff tests: use "git xyzzy" form (t0000 - t3599)
Converts tests between t0050-t3903.

Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-09-03 12:41:46 -07:00
Junio C Hamano
3af828634f tests: do not use implicit "git diff --no-index"
As a general principle, we should not use "git diff" to validate the
results of what git command that is being tested has done.  We would not
know if we are testing the command in question, or locating a bug in the
cute hack of "git diff --no-index".

Rather use test_cmp for that purpose.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-24 00:01:56 -07:00
Bryan Donlan
e5c349ba11 config.c: Escape backslashes in section names properly
If an element of the configuration key name other than the first or last
contains a backslash, it is not escaped on output, but is treated as an
escape sequence on input. Thus, the backslash is lost when re-loading
the configuration.

This patch corrects this by having backslashes escaped properly, and
introduces a new test for this bug.

Signed-off-by: Bryan Donlan <bdonlan@fushizen.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-05 14:17:00 -07:00
Jeff King
02e5ba4ae6 config: handle lack of newline at end of file better
The config parsing routines use the static global
'config_file' to store the FILE* pointing to the current
config file being parsed. The function get_next_char()
automatically converts an EOF on this file to a newline for
the convenience of its callers, and it sets config_file to
NULL to indicate that EOF was reached.

This throws away useful information, though, since some
routines want to call ftell on 'config_file' to find out
exactly _where_ the routine ended. In the case of a key
ending at EOF boundary, we ended up segfaulting in some
cases (changing that key or adding another key in its
section), or failing to provide the necessary newline
(adding a new section).

This patch adds a new flag to indicate EOF and uses that
instead of setting config_file to NULL. It also makes sure
to add newlines where necessary for truncated input. All
three included tests fail without the patch.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-02 02:28:54 -08:00