From: Junio C Hamano <hidden> Date: 2021-11-03 22:44:23
Ævar Arnfjörð Bjarmason [off-list ref] writes:
The CI target uses a new GIT_TEST_PASSING_SANITIZE_LEAK=true test
mode. When running in that mode, we'll assert that we were compiled
with SANITIZE=leak. We'll then skip all tests, except those that we've
opted-in by setting "TEST_PASSES_SANITIZE_LEAK=true".
...
This is how tests that don't set "TEST_PASSES_SANITIZE_LEAK=true" will
be skipped under GIT_TEST_PASSING_SANITIZE_LEAK=true:
I've been playing with this locally, but cannot shake the nagging
feeling that GIT_TEST_PASSING_SANITIZE_LEAK must default to true.
Otherwise, it is one more thing they need to find out and set when
they do
make SANITYZE=leak test
because they want to be a good developer and to ensure that they did
not introduce new leaks.
If we want to encourage folks to locally run the leak checks before
declaring their own work "done", that is.
Those who are hunting for and cleaning up existing leaks can and
should set it to false, no?
In any case, here is a small fallout out of my adventure into this
corner.
----- >8 --------- >8 --------- >8 --------- >8 -----
Subject: t0006: date_mode can leak .strftime_fmt member
As there is no date_mode_release() API function, and given the
set of current callers it probably is not worth adding one, let's
release the .strftime_fmt member that is obtained from strdup()
before the caller of show_date() is done with it.
This allows us to mark t0006 as passing under the leak sanitizer.
Signed-off-by: Junio C Hamano <redacted>
---
t/helper/test-date.c | 2 ++
t/t0006-date.sh | 2 ++
2 files changed, 4 insertions(+)
From: Junio C Hamano <hidden> Date: 2021-11-03 23:57:49
Junio C Hamano [off-list ref] writes:
Ævar Arnfjörð Bjarmason [off-list ref] writes:
quoted
The CI target uses a new GIT_TEST_PASSING_SANITIZE_LEAK=true test
mode. When running in that mode, we'll assert that we were compiled
with SANITIZE=leak. We'll then skip all tests, except those that we've
opted-in by setting "TEST_PASSES_SANITIZE_LEAK=true".
...
This is how tests that don't set "TEST_PASSES_SANITIZE_LEAK=true" will
be skipped under GIT_TEST_PASSING_SANITIZE_LEAK=true:
I've been playing with this locally, but cannot shake the nagging
feeling that GIT_TEST_PASSING_SANITIZE_LEAK must default to true.
Otherwise, it is one more thing they need to find out and set when
they do
make SANITYZE=leak test
because they want to be a good developer and to ensure that they did
not introduce new leaks.
If we want to encourage folks to locally run the leak checks before
declaring their own work "done", that is.
Those who are hunting for and cleaning up existing leaks can and
should set it to false, no?
Another thing while I am at it, I have a feeling that the polarity
of the TEST_PASSES_SANITIZE_LEAK declaration is the other way
around.
Marking the tests that do not yet pass the leak check with a special
annotation will make it easier to find not-yet-clean tests for those
who have too much time on their hands ;-) to find ones that are
affected by the leaky tests.
The CI target uses a new GIT_TEST_PASSING_SANITIZE_LEAK=true test
mode. When running in that mode, we'll assert that we were compiled
with SANITIZE=leak. We'll then skip all tests, except those that we've
opted-in by setting "TEST_PASSES_SANITIZE_LEAK=true".
...
This is how tests that don't set "TEST_PASSES_SANITIZE_LEAK=true" will
be skipped under GIT_TEST_PASSING_SANITIZE_LEAK=true:
I've been playing with this locally, but cannot shake the nagging
feeling that GIT_TEST_PASSING_SANITIZE_LEAK must default to true.
Otherwise, it is one more thing they need to find out and set when
they do
make SANITYZE=leak test
because they want to be a good developer and to ensure that they did
not introduce new leaks.
If we want to encourage folks to locally run the leak checks before
declaring their own work "done", that is.
Those who are hunting for and cleaning up existing leaks can and
should set it to false, no?
I agree that that would make a lot more sense and be more useful :)
That was the behavior of the patch I originally suggested for
integrating this SANITIZE=leak[1], but due to feedback on it I ended up
keeping the pre-image behavior of how SANITIZE=leak worked, unless there
were any opt-in test modes etc. in play:
https://lore.kernel.org/git/patch-1.4-a61a294132-20210714T001007Z-avarab@gmail.com/
I think at this point it's probably better to just keep it as it is...
quoted hunk
in any case, here is a small fallout out of my adventure into this
corner.
----- >8 --------- >8 --------- >8 --------- >8 -----
Subject: t0006: date_mode can leak .strftime_fmt member
As there is no date_mode_release() API function, and given the
set of current callers it probably is not worth adding one, let's
release the .strftime_fmt member that is obtained from strdup()
before the caller of show_date() is done with it.
This allows us to mark t0006 as passing under the leak sanitizer.
Signed-off-by: Junio C Hamano <redacted>
---
t/helper/test-date.c | 2 ++
t/t0006-date.sh | 2 ++
2 files changed, 4 insertions(+)
I'd notice that failure before, but hadn't looked into it. That was
easier to fix than I thought.
This fix looks good to me, except that you also need to change this at
the top:
I.e. this makes this specific thing pass, but in other tests we'd end up
freeing a non-NULL and randomly initialized pointer unless we init it to
zero.
From: Junio C Hamano <redacted>
As there is no date_mode_release() API function, and given the
set of current callers it probably is not worth adding one, let's
release the .strftime_fmt member that is obtained from strdup()
before the caller of show_date() is done with it.
This allows us to mark t0006 as passing under the leak sanitizer.
Signed-off-by: Junio C Hamano <redacted>
Signed-off-by: Ævar Arnfjörð Bjarmason <redacted>
---
A trivial leak test from Junio that fell between the cracks. Submitted
with my suggested fix-up in
https://lore.kernel.org/git/211104.86mtmki5ol.gmgdl@evledraar.gmail.com/
t/helper/test-date.c | 4 +++-
t/t0006-date.sh | 2 ++
2 files changed, 5 insertions(+), 1 deletion(-)
From: Jeff King <hidden> Date: 2021-11-16 19:31:34
On Tue, Nov 16, 2021 at 07:31:12PM +0100, Ævar Arnfjörð Bjarmason wrote:
As there is no date_mode_release() API function, and given the
set of current callers it probably is not worth adding one, let's
release the .strftime_fmt member that is obtained from strdup()
before the caller of show_date() is done with it.
It does feel a bit ugly to assume that we can touch strftime_fmt here,
especially since we don't even confirm that we parsed DATE_STRFTIME.
You initialize it as NULL and the current code doesn't touch it
otherwise, so there's no bug. But it would be reasonable for other date
formats to store ancillary data as a union with strftime_fmt, which
would invalidate this.
It also seems like other callers will need to do similar cleanup. E.g.,
"git -c log.date=format:foo log" has the same leak. So maybe it is worth
adding an actual cleanup function.
-Peff
This is a follow-up to a much smaller patch[1] discussed in November
to make t0006-date.sh pass with SANITIZE=leak.
In reply Jeff King pointed out that reaching into its private guts in
the test helper felt ugly[2].
So this series pursues a more thorough approach, creating a date.h,
moving our date functions there out of cache.h, documenting the core
functions, and finally adding and using a date_mode_release()
function.
It's definitely taking the long way around, but I think that the end
result is worth it. I then have a follow-up series to plug memory
leaks in revision.h, which will make use of this new API.
1. https://lore.kernel.org/git/patch-1.1-15f5bd3e4f4-20211116T183025Z-avarab@gmail.com/
2. https://lore.kernel.org/git/YZQHEiFnOdyxYX5t@coredump.intra.peff.net/
Ævar Arnfjörð Bjarmason (5):
cache.h: remove always unused show_date_human() declaration
date API: create a date.h, split from cache.h
date API: provide and use a DATE_MODE_INIT
date API: add basic API docs
date API: add and use a date_mode_release()
archive-zip.c | 1 +
builtin/am.c | 1 +
builtin/commit.c | 1 +
builtin/fast-import.c | 1 +
builtin/show-branch.c | 1 +
builtin/tag.c | 1 +
cache.h | 50 -----------------------------
config.c | 1 +
date.c | 9 ++++--
date.h | 73 +++++++++++++++++++++++++++++++++++++++++++
http-backend.c | 1 +
ident.c | 1 +
object-name.c | 1 +
pretty.h | 10 ++++++
ref-filter.c | 3 +-
refs.c | 1 +
strbuf.c | 1 +
t/helper/test-date.c | 5 ++-
t/t0006-date.sh | 2 ++
19 files changed, 110 insertions(+), 54 deletions(-)
create mode 100644 date.h
--
2.35.0.913.g12b4baa2536
There has never been a show_date_human() function on the "master"
branch in git.git. This declaration was added in b841d4ff438 (Add
`human` format to test-tool, 2019-01-28).
A look at the ML history reveals that it was leftover cruft from an
earlier version of that commit[1].
1. https://lore.kernel.org/git/20190118061805.19086-5-ischis2@cox.net/
Signed-off-by: Ævar Arnfjörð Bjarmason <redacted>
---
cache.h | 2 --
1 file changed, 2 deletions(-)
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.
Signed-off-by: Ævar Arnfjörð Bjarmason <redacted>
---
archive-zip.c | 1 +
builtin/am.c | 1 +
builtin/commit.c | 1 +
builtin/fast-import.c | 1 +
builtin/show-branch.c | 1 +
builtin/tag.c | 1 +
cache.h | 48 -------------------------------------------
config.c | 1 +
date.c | 1 +
date.h | 43 ++++++++++++++++++++++++++++++++++++++
http-backend.c | 1 +
ident.c | 1 +
object-name.c | 1 +
pretty.h | 10 +++++++++
refs.c | 1 +
strbuf.c | 1 +
t/helper/test-date.c | 1 +
17 files changed, 67 insertions(+), 48 deletions(-)
create mode 100644 date.h
Provide and use a DATE_MODE_INIT macro. Most of the users of struct
date_mode" use it via pretty.h's "struct pretty_print_context" which
doesn't have an initialization macro, so we're still bound to being
initialized to "{ 0 }" by default.
But we can change the couple of callers that directly declared a
variable on the stack to instead use the initializer, and thus do away
with the "mode.local = 0" added in add00ba2de9 (date: make "local"
orthogonal to date format, 2015-09-03).
Signed-off-by: Ævar Arnfjörð Bjarmason <redacted>
---
date.c | 3 +--
date.h | 4 ++++
ref-filter.c | 2 +-
t/helper/test-date.c | 2 +-
4 files changed, 7 insertions(+), 4 deletions(-)
Add basic API doc comments to date.h, and while doing so move the the
parse_date_format() function adjacent to show_date(). This way all the
"struct date_mode" functions are grouped together. Documenting the
rest is one of our #leftoverbits.
Signed-off-by: Ævar Arnfjörð Bjarmason <redacted>
---
date.h | 23 +++++++++++++++++++++--
1 file changed, 21 insertions(+), 2 deletions(-)
@@ -1,6 +1,12 @@#ifndef DATE_H#define DATE_H+/**+*Thedatemodetype.ThishasDATE_NORMALatanexplicit"= 0"to+*accommodateamemset([...],0,[...])initializationwhen"struct+*date_mode" is used as an embedded struct member, as in the case of+*e.g."struct pretty_print_context"and"struct rev_info".+*/enumdate_mode_type{DATE_NORMAL=0,DATE_HUMAN,
Fix a memory leak in the parse_date_format() function by providing a
new date_mode_release() companion function.
By using this in "t/helper/test-date.c" we can mark the
"t0006-date.sh" test as passing when git is compiled with
SANITIZE=leak, and whitelist it to run under
"GIT_TEST_PASSING_SANITIZE_LEAK=true" by adding
"TEST_PASSES_SANITIZE_LEAK=true" to the test itself.
The other tests that expose this memory leak (i.e. take the
"mode->type == DATE_STRFTIME" branch in parse_date_format()) are
"t6300-for-each-ref.sh" and "t7004-tag.sh". The former is due to an
easily fixed leak in "ref-filter.c", and brings the failures in
"t6300-for-each-ref.sh" down from 51 to 48.
Fixing the remaining leaks will have to wait until there's a
release_revisions() in "revision.c", as they have to do with leaks via
"struct rev_info".
Signed-off-by: Ævar Arnfjörð Bjarmason <redacted>
---
date.c | 5 +++++
date.h | 9 ++++++++-
ref-filter.c | 1 +
t/helper/test-date.c | 2 ++
t/t0006-date.sh | 2 ++
5 files changed, 18 insertions(+), 1 deletion(-)
On Wed, Feb 02 2022, Ævar Arnfjörð Bjarmason wrote:
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.
Signed-off-by: Ævar Arnfjörð Bjarmason <redacted>
---
archive-zip.c | 1 +
builtin/am.c | 1 +
builtin/commit.c | 1 +
builtin/fast-import.c | 1 +
builtin/show-branch.c | 1 +
builtin/tag.c | 1 +
cache.h | 48 -------------------------------------------
config.c | 1 +
date.c | 1 +
date.h | 43 ++++++++++++++++++++++++++++++++++++++
http-backend.c | 1 +
ident.c | 1 +
object-name.c | 1 +
pretty.h | 10 +++++++++
refs.c | 1 +
strbuf.c | 1 +
t/helper/test-date.c | 1 +
17 files changed, 67 insertions(+), 48 deletions(-)
create mode 100644 date.h
I managed to notice just after hitting "send" that I'd forgotten to
"make hdr-check". This commit will need the below fix-up. I'll hold off
on a v2 for now for any further comments though:
There has never been a show_date_human() function on the "master"
branch in git.git. This declaration was added in b841d4ff438 (Add
`human` format to test-tool, 2019-01-28).
A look at the ML history reveals that it was leftover cruft from an
earlier version of that commit[1].
1. https://lore.kernel.org/git/20190118061805.19086-5-ischis2@cox.net/
Signed-off-by: Ævar Arnfjörð Bjarmason <redacted>
---
cache.h | 2 --
1 file changed, 2 deletions(-)
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.
Signed-off-by: Ævar Arnfjörð Bjarmason <redacted>
---
archive-zip.c | 1 +
builtin/am.c | 1 +
builtin/commit.c | 1 +
builtin/fast-import.c | 1 +
builtin/show-branch.c | 1 +
builtin/tag.c | 1 +
cache.h | 48 -------------------------------------------
config.c | 1 +
date.c | 1 +
date.h | 43 ++++++++++++++++++++++++++++++++++++++
http-backend.c | 1 +
ident.c | 1 +
object-name.c | 1 +
pretty.h | 10 +++++++++
reflog-walk.h | 1 +
refs.c | 1 +
strbuf.c | 1 +
t/helper/test-date.c | 1 +
18 files changed, 68 insertions(+), 48 deletions(-)
create mode 100644 date.h
Provide and use a DATE_MODE_INIT macro. Most of the users of struct
date_mode" use it via pretty.h's "struct pretty_print_context" which
doesn't have an initialization macro, so we're still bound to being
initialized to "{ 0 }" by default.
But we can change the couple of callers that directly declared a
variable on the stack to instead use the initializer, and thus do away
with the "mode.local = 0" added in add00ba2de9 (date: make "local"
orthogonal to date format, 2015-09-03).
Signed-off-by: Ævar Arnfjörð Bjarmason <redacted>
---
date.c | 3 +--
date.h | 4 ++++
ref-filter.c | 2 +-
t/helper/test-date.c | 2 +-
4 files changed, 7 insertions(+), 4 deletions(-)
Add basic API doc comments to date.h, and while doing so move the the
parse_date_format() function adjacent to show_date(). This way all the
"struct date_mode" functions are grouped together. Documenting the
rest is one of our #leftoverbits.
Signed-off-by: Ævar Arnfjörð Bjarmason <redacted>
---
date.h | 23 +++++++++++++++++++++--
1 file changed, 21 insertions(+), 2 deletions(-)
@@ -1,6 +1,12 @@#ifndef DATE_H#define DATE_H+/**+*Thedatemodetype.ThishasDATE_NORMALatanexplicit"= 0"to+*accommodateamemset([...],0,[...])initializationwhen"struct+*date_mode" is used as an embedded struct member, as in the case of+*e.g."struct pretty_print_context"and"struct rev_info".+*/enumdate_mode_type{DATE_NORMAL=0,DATE_HUMAN,
Fix a memory leak in the parse_date_format() function by providing a
new date_mode_release() companion function.
By using this in "t/helper/test-date.c" we can mark the
"t0006-date.sh" test as passing when git is compiled with
SANITIZE=leak, and whitelist it to run under
"GIT_TEST_PASSING_SANITIZE_LEAK=true" by adding
"TEST_PASSES_SANITIZE_LEAK=true" to the test itself.
The other tests that expose this memory leak (i.e. take the
"mode->type == DATE_STRFTIME" branch in parse_date_format()) are
"t6300-for-each-ref.sh" and "t7004-tag.sh". The former is due to an
easily fixed leak in "ref-filter.c", and brings the failures in
"t6300-for-each-ref.sh" down from 51 to 48.
Fixing the remaining leaks will have to wait until there's a
release_revisions() in "revision.c", as they have to do with leaks via
"struct rev_info".
Signed-off-by: Ævar Arnfjörð Bjarmason <redacted>
---
date.c | 5 +++++
date.h | 9 ++++++++-
ref-filter.c | 1 +
t/helper/test-date.c | 2 ++
t/t0006-date.sh | 2 ++
5 files changed, 18 insertions(+), 1 deletion(-)
Junio: I think this series may have fallen between the cracks. Any
chance you're willing to pick this up? I'm keen to submit the larger
revision.[ch] leak fixes in this cycle, and this is one of the few
remaining dependencies for that.
Ævar Arnfjörð Bjarmason (5):
cache.h: remove always unused show_date_human() declaration
date API: create a date.h, split from cache.h
date API: provide and use a DATE_MODE_INIT
date API: add basic API docs
date API: add and use a date_mode_release()
archive-zip.c | 1 +
builtin/am.c | 1 +
builtin/commit.c | 1 +
builtin/fast-import.c | 1 +
builtin/show-branch.c | 1 +
builtin/tag.c | 1 +
cache.h | 50 -----------------------------
config.c | 1 +
date.c | 9 ++++--
date.h | 73 +++++++++++++++++++++++++++++++++++++++++++
http-backend.c | 1 +
ident.c | 1 +
object-name.c | 1 +
pretty.h | 10 ++++++
ref-filter.c | 3 +-
reflog-walk.h | 1 +
refs.c | 1 +
strbuf.c | 1 +
t/helper/test-date.c | 5 ++-
t/t0006-date.sh | 2 ++
20 files changed, 111 insertions(+), 54 deletions(-)
create mode 100644 date.h
Range-diff against v1:
1: fb21bd7b2c5 = 1: fb21bd7b2c5 cache.h: remove always unused show_date_human() declaration
2: 7de62956db4 ! 2: 96c904d0b9a date API: create a date.h, split from cache.h
@@ pretty.h: int format_set_trailers_options(struct process_trailer_options *opts,
+
#endif /* PRETTY_H */
+ ## reflog-walk.h ##
+@@
+
+ struct commit;
+ struct reflog_walk_info;
++struct date_mode;
+
+ void init_reflog_walk(struct reflog_walk_info **info);
+ int add_reflog_for_walk(struct reflog_walk_info *info,
+
## refs.c ##
@@
#include "strvec.h"
3: 2d5210f9421 = 3: 9ef003a83bd date API: provide and use a DATE_MODE_INIT
4: aab2ae9cc72 = 4: 3f70b1aa4c5 date API: add basic API docs
5: b67e23549ed = 5: 60dbadacb16 date API: add and use a date_mode_release()
From: Junio C Hamano <hidden> Date: 2022-02-15 02:14:31
Ævar Arnfjörð Bjarmason [off-list ref] writes:
+/**
+ * Show the date given an initialized "struct date_mode" (usually from
+ * the DATE_MODE() macro).
+ */
const char *show_date(timestamp_t time, int timezone, const struct date_mode *mode);
It's a bit of wasted bytes to explain "show_date()" as "show". In
the context of this function, the verb "show" in its name does not
mean emitting to any output stream, but return a short-lived memory
stuffed with a date string formatted according to the date mode
that the caller needs to either immediately consume or strdup() away
if it wants to use it later, which is a lot more helpful thing to
tell to the readers.
/**
* Format <'time', 'timezone'> into static memory according to
* 'mode' and return it.
*/
or something along that line?
From: Junio C Hamano <hidden> Date: 2022-02-15 03:04:34
Ævar Arnfjörð Bjarmason [off-list ref] writes:
Move the declaration of the date.c functions from cache.h, and adjust
the relevant users to include the new date.h header.
It makes the patch larger than it could be to split off part of
cache.h into a new header and force users to include the new date.h
in the same commit, rather than first including date.h in cache.h
so that users do not have to change, and then update the inclusion
in a separate follow-up commit. The end result looks OK, though.
There has never been a show_date_human() function on the "master"
branch in git.git. This declaration was added in b841d4ff438 (Add
`human` format to test-tool, 2019-01-28).
A look at the ML history reveals that it was leftover cruft from an
earlier version of that commit[1].
1. https://lore.kernel.org/git/20190118061805.19086-5-ischis2@cox.net/
Signed-off-by: Ævar Arnfjörð Bjarmason <redacted>
---
cache.h | 2 --
1 file changed, 2 deletions(-)
Fix memory leaks in the date.[ch] API, in preparation for larger
changes to make the revision walking API stop leaking memory.
This is small re-roll of v2 to address Junio's feedback on that
version. For v2 see:
https://lore.kernel.org/git/cover-v2-0.5-00000000000-20220204T235143Z-avarab@gmail.com/
This is a documentation and commit-message only update. As explained
below I think it makes sense to punt on the "builtin/blame.c" leak,
and to keep 2/5 as-is with date.h not included in cache.h, but those
things are now all rationalized in the commit message. Thanks for the
review Junio!
Ævar Arnfjörð Bjarmason (5):
cache.h: remove always unused show_date_human() declaration
date API: create a date.h, split from cache.h
date API: provide and use a DATE_MODE_INIT
date API: add basic API docs
date API: add and use a date_mode_release()
archive-zip.c | 1 +
builtin/am.c | 1 +
builtin/commit.c | 1 +
builtin/fast-import.c | 1 +
builtin/show-branch.c | 1 +
builtin/tag.c | 1 +
cache.h | 50 -----------------------------
config.c | 1 +
date.c | 9 ++++--
date.h | 74 +++++++++++++++++++++++++++++++++++++++++++
http-backend.c | 1 +
ident.c | 1 +
object-name.c | 1 +
pretty.h | 10 ++++++
ref-filter.c | 3 +-
reflog-walk.h | 1 +
refs.c | 1 +
strbuf.c | 1 +
t/helper/test-date.c | 5 ++-
t/t0006-date.sh | 2 ++
20 files changed, 112 insertions(+), 54 deletions(-)
create mode 100644 date.h
Range-diff against v2:
1: fb21bd7b2c5 = 1: 97746d97810 cache.h: remove always unused show_date_human() declaration
2: 96c904d0b9a ! 2: f73aa601e95 date API: create a date.h, split from cache.h
@@ Commit message
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 [off-list ref]
## archive-zip.c ##
3: 9ef003a83bd = 3: 764147e90e1 date API: provide and use a DATE_MODE_INIT
4: 3f70b1aa4c5 ! 4: 5c244960133 date API: add basic API docs
@@ date.h: struct date_mode {
struct date_mode *date_mode_from_type(enum date_mode_type type);
+/**
-+ * Show the date given an initialized "struct date_mode" (usually from
-+ * the DATE_MODE() macro).
++ * Format <'time', 'timezone'> into static memory according to 'mode'
++ * and return it. The mode is an initialized "struct date_mode"
++ * (usually from the DATE_MODE() macro).
+ */
const char *show_date(timestamp_t time, int timezone, const struct date_mode *mode);
+
5: 60dbadacb16 ! 5: b1ee9a30913 date API: add and use a date_mode_release()
@@ Commit message
release_revisions() in "revision.c", as they have to do with leaks via
"struct rev_info".
+ There is also a leak in "builtin/blame.c" due to its call to
+ parse_date_format() to parse the "blame.date" configuration. However
+ as it declares a file-level "static struct date_mode blame_date_mode"
+ to track the data, LSAN will not report it as a leak. It's possible to
+ get valgrind(1) to complain about it with e.g.:
+
+ valgrind --leak-check=full --show-leak-kinds=all ./git -P -c blame.date=format:%Y blame README.md
+
+ But let's focus on things LSAN complains about, and are thus
+ observable with "TEST_PASSES_SANITIZE_LEAK=true". We should get to
+ fixing memory leaks in "builtin/blame.c", but as doing so would
+ require some re-arrangement of cmd_blame() let's leave it for some
+ other time.
+
Signed-off-by: Ævar Arnfjörð Bjarmason [off-list ref]
## date.c ##
--
2.35.1.1028.g2d2d4be19de
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 <redacted>
---
archive-zip.c | 1 +
builtin/am.c | 1 +
builtin/commit.c | 1 +
builtin/fast-import.c | 1 +
builtin/show-branch.c | 1 +
builtin/tag.c | 1 +
cache.h | 48 -------------------------------------------
config.c | 1 +
date.c | 1 +
date.h | 43 ++++++++++++++++++++++++++++++++++++++
http-backend.c | 1 +
ident.c | 1 +
object-name.c | 1 +
pretty.h | 10 +++++++++
reflog-walk.h | 1 +
refs.c | 1 +
strbuf.c | 1 +
t/helper/test-date.c | 1 +
18 files changed, 68 insertions(+), 48 deletions(-)
create mode 100644 date.h
Provide and use a DATE_MODE_INIT macro. Most of the users of struct
date_mode" use it via pretty.h's "struct pretty_print_context" which
doesn't have an initialization macro, so we're still bound to being
initialized to "{ 0 }" by default.
But we can change the couple of callers that directly declared a
variable on the stack to instead use the initializer, and thus do away
with the "mode.local = 0" added in add00ba2de9 (date: make "local"
orthogonal to date format, 2015-09-03).
Signed-off-by: Ævar Arnfjörð Bjarmason <redacted>
---
date.c | 3 +--
date.h | 4 ++++
ref-filter.c | 2 +-
t/helper/test-date.c | 2 +-
4 files changed, 7 insertions(+), 4 deletions(-)
Add basic API doc comments to date.h, and while doing so move the the
parse_date_format() function adjacent to show_date(). This way all the
"struct date_mode" functions are grouped together. Documenting the
rest is one of our #leftoverbits.
Signed-off-by: Ævar Arnfjörð Bjarmason <redacted>
---
date.h | 24 ++++++++++++++++++++++--
1 file changed, 22 insertions(+), 2 deletions(-)
@@ -1,6 +1,12 @@#ifndef DATE_H#define DATE_H+/**+*Thedatemodetype.ThishasDATE_NORMALatanexplicit"= 0"to+*accommodateamemset([...],0,[...])initializationwhen"struct+*date_mode" is used as an embedded struct member, as in the case of+*e.g."struct pretty_print_context"and"struct rev_info".+*/enumdate_mode_type{DATE_NORMAL=0,DATE_HUMAN,
Fix a memory leak in the parse_date_format() function by providing a
new date_mode_release() companion function.
By using this in "t/helper/test-date.c" we can mark the
"t0006-date.sh" test as passing when git is compiled with
SANITIZE=leak, and whitelist it to run under
"GIT_TEST_PASSING_SANITIZE_LEAK=true" by adding
"TEST_PASSES_SANITIZE_LEAK=true" to the test itself.
The other tests that expose this memory leak (i.e. take the
"mode->type == DATE_STRFTIME" branch in parse_date_format()) are
"t6300-for-each-ref.sh" and "t7004-tag.sh". The former is due to an
easily fixed leak in "ref-filter.c", and brings the failures in
"t6300-for-each-ref.sh" down from 51 to 48.
Fixing the remaining leaks will have to wait until there's a
release_revisions() in "revision.c", as they have to do with leaks via
"struct rev_info".
There is also a leak in "builtin/blame.c" due to its call to
parse_date_format() to parse the "blame.date" configuration. However
as it declares a file-level "static struct date_mode blame_date_mode"
to track the data, LSAN will not report it as a leak. It's possible to
get valgrind(1) to complain about it with e.g.:
valgrind --leak-check=full --show-leak-kinds=all ./git -P -c blame.date=format:%Y blame README.md
But let's focus on things LSAN complains about, and are thus
observable with "TEST_PASSES_SANITIZE_LEAK=true". We should get to
fixing memory leaks in "builtin/blame.c", but as doing so would
require some re-arrangement of cmd_blame() let's leave it for some
other time.
Signed-off-by: Ævar Arnfjörð Bjarmason <redacted>
---
date.c | 5 +++++
date.h | 9 ++++++++-
ref-filter.c | 1 +
t/helper/test-date.c | 2 ++
t/t0006-date.sh | 2 ++
5 files changed, 18 insertions(+), 1 deletion(-)