141e13ee1a
The macro check_strvec calls the function check_strvec_loc(), which performs the actual checks. They report the line number inside that function on error, which is not very helpful. Before the previous patch half of them triggered an assertion that reported the caller's line number using a custom message, which was more useful, but a bit awkward. Improve the output by getting rid of check_strvec_loc() and performing all checks within check_strvec, as they then report the line number of the call site, aiding in finding the broken test. Determine the number of items and check it up front to avoid having to do them both in the loop and at the end. Sanity check the expected items to make sure there are any and that the last one is NULL, as the compiler no longer does that for us with the removal of the function attribute LAST_ARG_MUST_BE_NULL. Use only the actual strvec name passed to the macro, the internal "expect" array name and an index "i" in the output, for clarity. While "expect" does not exist at the call site, it's reasonably easy to infer that it's referring to the NULL-terminated list of expected strings, converted to an array. Here's the output with less items than expected in the strvec before: # check "vec->nr > nr" failed at t/unit-tests/t-strvec.c:19 # left: 1 # right: 1 ... and with the patch: # check "(&vec)->nr == ARRAY_SIZE(expect) - 1" failed at t/unit-tests/t-strvec.c:53 # left: 1 # right: 2 With too many items in the strvec we got before: # check "vec->nr == nr" failed at t/unit-tests/t-strvec.c:34 # left: 1 # right: 0 # check "vec->v[nr] == NULL" failed at t/unit-tests/t-strvec.c:36 # left: 0x6000004b8010 # right: 0x0 ... and with the patch: # check "(&vec)->nr == ARRAY_SIZE(expect) - 1" failed at t/unit-tests/t-strvec.c:53 # left: 1 # right: 0 A broken alloc value was reported like this: # check "vec->alloc > nr" failed at t/unit-tests/t-strvec.c:20 # left: 0 # right: 0 ... and with the patch: # check "(&vec)->nr <= (&vec)->alloc" failed at t/unit-tests/t-strvec.c:56 # left: 2 # right: 0 An unexpected string value was reported like this: # check "!strcmp(vec->v[nr], str)" failed at t/unit-tests/t-strvec.c:24 # left: "foo" # right: "bar" # nr: 0 ... and with the patch: # check "!strcmp((&vec)->v[i], expect[i])" failed at t/unit-tests/t-strvec.c:53 # left: "foo" # right: "bar" # i: 0 If the strvec is not NULL terminated, we got: # check "vec->v[nr] == NULL" failed at t/unit-tests/t-strvec.c:36 # left: 0x102c3abc8 # right: 0x0 ... and with the patch we get the line number of the caller: # check "!strcmp((&vec)->v[i], expect[i])" failed at t/unit-tests/t-strvec.c:53 # left: "bar" # right: NULL # i: 1 check_strvec calls without a trailing NULL were detected at compile time before: t/unit-tests/t-strvec.c:71:2: error: missing sentinel in function call [-Werror,-Wsentinel] ... and with the patch it's only found at runtime: # check "expect[ARRAY_SIZE(expect) - 1] == NULL" failed at t/unit-tests/t-strvec.c:53 # left: 0x100e5a663 # right: 0x0 We can let check_strvec add the terminating NULL for us and remove it from callers, making it impossible to forget. Leave that conversion for a future patch, though, since this reimplementation is already intrusive enough. Reported-by: Jeff King <peff@peff.net> Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Git - fast, scalable, distributed revision control system
Git is a fast, scalable, distributed revision control system with an unusually rich command set that provides both high-level operations and full access to internals.
Git is an Open Source project covered by the GNU General Public License version 2 (some parts of it are under different licenses, compatible with the GPLv2). It was originally written by Linus Torvalds with help of a group of hackers around the net.
Please read the file INSTALL for installation instructions.
Many Git online resources are accessible from https://git-scm.com/ including full documentation and Git related tools.
See Documentation/gittutorial.txt to get started, then see
Documentation/giteveryday.txt for a useful minimum set of commands, and
Documentation/git-<commandname>.txt for documentation of each command.
If git has been correctly installed, then the tutorial can also be
read with man gittutorial or git help tutorial, and the
documentation of each command with man git-<commandname> or git help <commandname>.
CVS users may also want to read Documentation/gitcvs-migration.txt
(man gitcvs-migration or git help cvs-migration if git is
installed).
The user discussion and development of Git take place on the Git mailing list -- everyone is welcome to post bug reports, feature requests, comments and patches to git@vger.kernel.org (read Documentation/SubmittingPatches for instructions on patch submission and Documentation/CodingGuidelines).
Those wishing to help with error message, usage and informational message
string translations (localization l10) should see po/README.md
(a po file is a Portable Object file that holds the translations).
To subscribe to the list, send an email to git+subscribe@vger.kernel.org (see https://subspace.kernel.org/subscribing.html for details). The mailing list archives are available at https://lore.kernel.org/git/, https://marc.info/?l=git and other archival sites.
Issues which are security relevant should be disclosed privately to the Git Security mailing list git-security@googlegroups.com.
The maintainer frequently sends the "What's cooking" reports that list the current status of various development topics to the mailing list. The discussion following them give a good reference for project status, development direction and remaining tasks.
The name "git" was given by Linus Torvalds when he wrote the very first version. He described the tool as "the stupid content tracker" and the name as (depending on your mood):
- random three-letter combination that is pronounceable, and not actually used by any common UNIX command. The fact that it is a mispronunciation of "get" may or may not be relevant.
- stupid. contemptible and despicable. simple. Take your pick from the dictionary of slang.
- "global information tracker": you're in a good mood, and it actually works for you. Angels sing, and a light suddenly fills the room.
- "goddamn idiotic truckload of sh*t": when it breaks