On Wed, Oct 17, 2012 at 10:45:25PM -0700, Junio C Hamano wrote:

> +     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_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.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to