Re: Potential Null Pointer Dereference detected by static analysis tool

From: Jeff King <peff@peff.net>
Date: Aug 18, 2025, 20:56 UTC
Message-ID: <20250818205608.GA1018532@coredump.intra.peff.net>
In-Reply-To: <20250818202140.GA1014353@coredump.intra.peff.net>

On Mon, Aug 18, 2025 at 04:21:40PM -0400, Jeff King wrote:

Show 15 quoted lines

> >   5. When process_object() has a commit, but it is indescribable, it
> >      shows an error:
> > 
> >      $ git describe 5afbe6da1d6ab0b8939343166636b828e561bf35
> >      fatal: No tags can describe '3b681e255cd8577a77983958ef7f566b05806cd0'.
> >      Try --always, or create some tags.
> > 
> >      It's not immediately clear that the reported hash belongs to the
> >      found commit.  And that suggestion to try --always is misleading,
> >      as "git describe <blob>" takes no options according to the
> >      documentation.  I'm not sure I like it in general -- can't tell
> >      if the command is being snarky with me.
> 
> Yeah, describe_commit()'s messages are not really set up to handle
> describing an arbitrary commit that the user did not specify.

Oh, there's one other related case I _thought_ was bug, but maybe isn't. If you don't have any tags at all, then we'll bail immediately:

  $ git init
  $ echo foo >file && git add file && git commit -m foo
  $ git describe $(git rev-parse HEAD:file)
  fatal: No names found, cannot describe anything.

But we're traversing from HEAD, not the tags, so my initial thought was that this should work. But of course it doesn't because we try to describe the containing commit, which _does_ require tags.

And that leads back to: "well, you could pass --always". Which disagrees with the documentation, but I think does actually do something useful here.

-Peff