git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 3/6] pretty: prepare notes message at a centralized place

From
Jeff King <peff@peff.net>
Date
Oct 18, 2012, 07:49 UTC
Message-ID
<20121018074921.GC9999@sigill.intra.peff.net>
In-Reply-To
<1350539128-21577-4-git-send-email-gitster@pobox.com>
On Wed, Oct 17, 2012 at 10:45:25PM -0700, Junio C Hamano wrote:
Show 11 quoted lines
> +	if (opt->show_notes) {
> +		int raw;
> +		struct strbuf notebuf = STRBUF_INIT;
> +
> +		raw = (opt->commit_format == CMIT_FMT_USERFORMAT);
> +		format_display_notes(commit->object.sha1, &notebuf,
> +				     get_log_output_encoding(), raw);
> +		ctx.notes_message = notebuf.len
> +			? strbuf_detach(&notebuf, NULL)
> +			: xcalloc(1, 1);
> +	}

This last line seems like it is caused by a bug in the strbuf API. Detaching an empty string will sometimes get you NULL and sometimes not. For example, this:

  struct strbuf foo = STRBUF_INIT;
  strbuf_detach(&foo, NULL);
will return NULL. But this:
  struct strbuf foo = STRBUF_INIT;
  strbuf_addstr(&foo, "bar");
  strbuf_reset(&foo);
  strbuf_detach(&foo, NULL);

will get you a zero-length string. Which just seems insane to me. The whole point of strbuf_detach is that you do not have to care about the internal representation. It should probably always return a newly allocated zero-length string.

Looking through a few uses of strbuf_detach, it looks like callers assume they will always get a pointer from strbuf_detach, and we are saved by implementation details. For example, sha1_file_to_archive might have an empty file, but the fact that strbuf_attach always allocates a byte means that the detach will never return NULL. Similarly, argv_array_pushf would never want to turn an empty string into an accidental NULL; it is saved by the fact that strbuf_vaddf will always preemptively allocate 64 bytes.

It's possible that switching it would create bugs elsewhere (there are over 100 uses of strbuf_detach, so maybe somebody really does want this NULL behavior), but I tend to think it is just as likely to be fixing undiscovered bugs.

-Peff
Previous: Junio C HamanoNext: Junio C Hamano
Message 5 of 19 in “Bring "format-patch --notes" closer to a real feature”
  1. 0/6 Bring "format-patch --notes" closer to a real featureJunio C Hamano, Oct 18, 2012
  2. 1/6 pretty: remove reencode_commit_message()Junio C Hamano, Oct 18, 2012
  3. 2/6 format_note(): simplify APIJunio C Hamano, Oct 18, 2012
  4. 3/6 pretty: prepare notes message at a centralized placeJunio C Hamano, Oct 18, 2012
  5. Jeff KingOct 18, 2012
  6. Junio C HamanoOct 18, 2012
  7. Jeff KingOct 18, 2012
  8. strbuf: always return a non-NULL value from strbuf_detachJeff King, Oct 18, 2012
  9. 4/6 pretty_print_commit(): do not append notes messageJunio C Hamano, Oct 18, 2012
  10. 5/6 format-patch: append --signature after notesJunio C Hamano, Oct 18, 2012
  11. 6/6 format-patch --notes: show notes after three-dashesJunio C Hamano, Oct 18, 2012
  12. Philip OakleyOct 18, 2012
  13. Junio C HamanoOct 18, 2012
  14. Junio C HamanoOct 19, 2012
  15. Philip OakleyOct 21, 2012
  16. Jeff KingOct 18, 2012
  17. Nguyen Thai Ngoc DuyOct 18, 2012
  18. Michael J GruberOct 18, 2012
  19. Junio C HamanoOct 18, 2012

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.