git/strbuf.c, branch v2.37.2

gettext API users: don't explicitly cast ngettext()'s "n"

2022-03-07T19:57:52Z

Change a few stray users of the inline gettext.h Q_() function to stop casting its "n" argument, the vast majority of the users of that wrapper API use the implicit cast to "unsigned long". The ngettext() function (which Q_() resolves to) takes an "unsigned long int", and so does our Q_() wrapper for it, see 0c9ea33b90f (i18n: add stub Q_() wrapper for ngettext, 2011-03-09). The function isn't ours, but provided by e.g. GNU libintl. This amends code added in added in 7171a0b0cf5 (index-pack: correct "len" type in unpack_data(), 2016-07-13). The cast it added for the printf format to die() was needed, but not the cast to Q_(). Likewise the casts in strbuf.c added in 8f354a1faed (l10n: localizable upload progress messages, 2019-07-02) and for builtin/merge-recursive.c in ccf7813139f (i18n: merge-recursive: mark error messages for translation, 2016-09-15) weren't needed. In the latter case the cast was copy/pasted from the argument to warning() itself, added in b74d779bd90 (MinGW: Fix compiler warning in merge-recursive, 2009-05-23). The cast for warning() is needed, but not the one for ngettext()'s "n" argument. Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

date API: create a date.h, split from cache.h

2022-02-16T17:40:00Z

Move the declaration of the date.c functions from cache.h, and adjust the relevant users to include the new date.h header. The show_ident_date() function belonged in pretty.h (it's defined in pretty.c), its two users outside of pretty.c didn't strictly need to include pretty.h, as they get it indirectly, but let's add it to them anyway. Similarly, the change to "builtin/{fast-import,show-branch,tag}.c" isn't needed as far as the compiler is concerned, but since they all use the "DATE_MODE()" macro we now define in date.h, let's have them include it. We could simply include this new header in "cache.h", but as this change shows these functions weren't common enough to warrant including in it in the first place. By moving them out of cache.h changes to this API will no longer cause a (mostly) full re-build of the project when "make" is run. Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

strbuf_addftime(): handle "%s" manually

2021-11-04T19:38:09Z

The strftime() function has a non-standard "%s" extension, which prints the number of seconds since the epoch. But the "struct tm" we get has already been adjusted for a particular time zone; going back to an epoch time requires knowing that zone offset. Since strftime() doesn't take such an argument, round-tripping to a "struct tm" and back to the "%s" format may produce the wrong value (off by tz_offset seconds). Since we're already passing in the zone offset courtesy of c3fbf81a85 (strbuf: let strbuf_addftime handle %z and %Z itself, 2017-06-15), we can use that same value to adjust our epoch seconds accordingly. Note that the description above makes it sound like strftime()'s "%s" is useless (and really, the issue is shared by mktime(), which is what strftime() would use under the hood). But it gets the two cases for which it's designed correct: - the result of gmtime() will have a zero offset, so no adjustment is necessary - the result of localtime() will be offset by the local zone offset, and mktime() and strftime() are defined to assume this offset when converting back (there's actually some magic here; some implementations record this in the "struct tm", but we can't portably access or manipulate it. But they somehow "know" whether a "struct tm" is from gmtime() or localtime()). This latter point means that "format-local:%s" actually works correctly already, because in that case we rely on the system routines due to 6eced3ec5e (date: use localtime() for "-local" time formats, 2017-06-15). Our problem comes when trying to show times in the author's zone, as the system routines provide no mechanism for converting in non-local zones. So in those cases we have a "struct tm" that came from gmtime(), but has been manipulated according to our offset. The tests cover the broken round-trip by formatting "%s" for a time in a non-system timezone. We use the made-up "+1234" here, which has two advantages. One, we know it won't ever be the real system zone (and so we're actually testing a case that would break). And two, since it has a minute component, we're testing the full decoding of the +HHMM zone into a number of seconds. Likewise, we test the "-1234" variant to make sure there aren't any sign mistakes. There's one final test, which covers "format-local:%s". As noted, this already passes, but it's important to check that we didn't regress this case. In particular, the caller in show_date() is relying on localtime() to have done the zone adjustment, independent of any tz_offset we compute ourselves. These should match up, since our local_tzoffset() is likewise built around localtime(). But it would be easy for a caller to forget to pass in a correct tz_offset to strbuf_addftime(). Fortunately show_date() does this correctly (it has to because of the existing handling of %z), and the test continues to pass. So this one is just future-proofing against a change in our assumptions. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

merge-{ort,recursive}: remove add_submodule_odb()

2021-10-08T22:06:06Z

After the parent commit and some of its ancestors, the only place commits are being accessed through alternates is in the user-facing message formatting code. Fix those, and remove the add_submodule_odb() calls. Signed-off-by: Jonathan Tan Signed-off-by: Junio C Hamano

.c _init(): define in terms of corresponding *_INIT macro

2021-07-01T19:32:22Z

Change the common patter in the codebase of duplicating the initialization logic between an *_INIT macro and a corresponding *_init() function to use the macro as the canonical source of truth. Now we no longer need to keep the function up-to-date with the macro version. This implements a suggestion by Jeff King who found that under -O2 [1] modern compilers will init new version in place without the extra copy[1]. The performance of a single *_init() won't matter in most cases, but even if it does we're going to be producing efficient machine code to perform these operations. 1. https://lore.kernel.org/git/YNyrDxUO1PlGJvCn@coredump.intra.peff.net/ Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

mailinfo: also free strbuf lists when clearing mailinfo

2021-04-28T00:25:45Z

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 Signed-off-by: Junio C Hamano

Merge branch 'rs/retire-strbuf-write-fd'

2020-06-29T21:17:26Z

A misdesigned strbuf_write_fd() function has been retired. * rs/retire-strbuf-write-fd: strbuf: remove unreferenced strbuf_write_fd method. bugreport.c: replace strbuf_write_fd with write_in_full

strbuf: remove unreferenced strbuf_write_fd method.

2020-06-19T20:50:27Z

strbuf_write_fd was only used in bugreport.c. Since that file now uses write_in_full, this method is no longer needed. In addition, strbuf_write_fd did not guard against exceeding MAX_IO_SIZE for the platform, nor provided error handling in the event of a failure if only partial data was written to the file descriptor. Since already write_in_full has this capability and is in general use, it should be used instead. The change impacts strbuf.c and strbuf.h. Signed-off-by: Randall S. Becker Signed-off-by: Junio C Hamano

Merge branch 'bc/wildcard-credential'

2020-05-05T21:54:26Z

Update the parser used for credential.. configuration, to handle s with '/' in them correctly. * bc/wildcard-credential: credential: fix matching URLs with multiple levels in path

Merge branch 'es/bugreport'

2020-05-01T20:39:59Z

The "bugreport" tool. * es/bugreport: bugreport: drop extraneous includes bugreport: add compiler info bugreport: add uname info bugreport: gather git version and build info bugreport: add tool to generate debugging info help: move list_config_help to builtin/help