diff mbox series

[1/2] stop calling UNLEAK() before die()

Message ID 20200813155500.GA897132@coredump.intra.peff.net (mailing list archive)
State Accepted
Commit d5e1961c19a2b638a700d03729cbb6c27fe5a3e8
Headers show
Series UNLEAK style fixes | expand

Commit Message

Jeff King Aug. 13, 2020, 3:55 p.m. UTC
The point of UNLEAK() is to make a reference to a variable that is about
to go out of scope so that leak-checkers will consider it to be
not-leaked. Doing so right before die() is therefore pointless; even
though we are about to exit the program, the variable will still be on
the stack and accessible to leak-checkers.

These annotations aren't really hurting anything, but they clutter the
code and set a bad example of how to use UNLEAK().

Signed-off-by: Jeff King <peff@peff.net>
---
 bugreport.c | 4 +---
 midx.c      | 8 ++------
 2 files changed, 3 insertions(+), 9 deletions(-)

Comments

Derrick Stolee Aug. 13, 2020, 6:08 p.m. UTC | #1
On 8/13/2020 11:55 AM, Jeff King wrote:
> The point of UNLEAK() is to make a reference to a variable that is about
> to go out of scope so that leak-checkers will consider it to be
> not-leaked. Doing so right before die() is therefore pointless; even
> though we are about to exit the program, the variable will still be on
> the stack and accessible to leak-checkers.
> 
> These annotations aren't really hurting anything, but they clutter the
> code and set a bad example of how to use UNLEAK().

Good justification. I'll stop being a bad example ;)

Thanks,
-Stolee

> Signed-off-by: Jeff King <peff@peff.net>
> ---
>  bugreport.c | 4 +---
>  midx.c      | 8 ++------
>  2 files changed, 3 insertions(+), 9 deletions(-)
> 
> diff --git a/bugreport.c b/bugreport.c
> index 09579e268d..7ca0fba1b8 100644
> --- a/bugreport.c
> +++ b/bugreport.c
> @@ -175,10 +175,8 @@ int cmd_main(int argc, const char **argv)
>  	/* fopen doesn't offer us an O_EXCL alternative, except with glibc. */
>  	report = open(report_path.buf, O_CREAT | O_EXCL | O_WRONLY, 0666);
>  
> -	if (report < 0) {
> -		UNLEAK(report_path);
> +	if (report < 0)
>  		die(_("couldn't create a new file at '%s'"), report_path.buf);
> -	}
>  
>  	if (write_in_full(report, buffer.buf, buffer.len) < 0)
>  		die_errno(_("unable to write to %s"), report_path.buf);
> diff --git a/midx.c b/midx.c
> index a5fb797ede..737420f157 100644
> --- a/midx.c
> +++ b/midx.c
> @@ -807,11 +807,9 @@ static int write_midx_internal(const char *object_dir, struct multi_pack_index *
>  	int result = 0;
>  
>  	midx_name = get_midx_filename(object_dir);
> -	if (safe_create_leading_directories(midx_name)) {
> -		UNLEAK(midx_name);
> +	if (safe_create_leading_directories(midx_name))
>  		die_errno(_("unable to create leading directories of %s"),
>  			  midx_name);
> -	}
>  
>  	if (m)
>  		packs.m = m;
> @@ -1051,10 +1049,8 @@ void clear_midx_file(struct repository *r)
>  		r->objects->multi_pack_index = NULL;
>  	}
>  
> -	if (remove_path(midx)) {
> -		UNLEAK(midx);
> +	if (remove_path(midx))
>  		die(_("failed to clear multi-pack-index at %s"), midx);
> -	}
>  
>  	free(midx);
>  }
>
Jeff King Aug. 14, 2020, 10:17 a.m. UTC | #2
On Thu, Aug 13, 2020 at 02:08:45PM -0400, Derrick Stolee wrote:

> On 8/13/2020 11:55 AM, Jeff King wrote:
> > The point of UNLEAK() is to make a reference to a variable that is about
> > to go out of scope so that leak-checkers will consider it to be
> > not-leaked. Doing so right before die() is therefore pointless; even
> > though we are about to exit the program, the variable will still be on
> > the stack and accessible to leak-checkers.
> > 
> > These annotations aren't really hurting anything, but they clutter the
> > code and set a bad example of how to use UNLEAK().
> 
> Good justification. I'll stop being a bad example ;)

To be fair, it seems clear that UNLEAK() as a concept is rather
confusing. I really never intended anybody to start sprinkling it around
the code. It was meant to be a tool for folks who are interested in
running leak-checkers to do in-code annotations (for "yes, I know this
leaks but not until the program effectively ends").

I certainly don't mind if people writing new code preemptively annotate
this kind of leak. But I also wouldn't really encourage authors to put a
lot of effort into it, given the current state of the annotations.

-Peff
diff mbox series

Patch

diff --git a/bugreport.c b/bugreport.c
index 09579e268d..7ca0fba1b8 100644
--- a/bugreport.c
+++ b/bugreport.c
@@ -175,10 +175,8 @@  int cmd_main(int argc, const char **argv)
 	/* fopen doesn't offer us an O_EXCL alternative, except with glibc. */
 	report = open(report_path.buf, O_CREAT | O_EXCL | O_WRONLY, 0666);
 
-	if (report < 0) {
-		UNLEAK(report_path);
+	if (report < 0)
 		die(_("couldn't create a new file at '%s'"), report_path.buf);
-	}
 
 	if (write_in_full(report, buffer.buf, buffer.len) < 0)
 		die_errno(_("unable to write to %s"), report_path.buf);
diff --git a/midx.c b/midx.c
index a5fb797ede..737420f157 100644
--- a/midx.c
+++ b/midx.c
@@ -807,11 +807,9 @@  static int write_midx_internal(const char *object_dir, struct multi_pack_index *
 	int result = 0;
 
 	midx_name = get_midx_filename(object_dir);
-	if (safe_create_leading_directories(midx_name)) {
-		UNLEAK(midx_name);
+	if (safe_create_leading_directories(midx_name))
 		die_errno(_("unable to create leading directories of %s"),
 			  midx_name);
-	}
 
 	if (m)
 		packs.m = m;
@@ -1051,10 +1049,8 @@  void clear_midx_file(struct repository *r)
 		r->objects->multi_pack_index = NULL;
 	}
 
-	if (remove_path(midx)) {
-		UNLEAK(midx);
+	if (remove_path(midx))
 		die(_("failed to clear multi-pack-index at %s"), midx);
-	}
 
 	free(midx);
 }