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

Re: [PATCH] strbuf_grow(): maintain nul-termination even for new buffer

From
Junio C Hamano <gitster@pobox.com>
Date
Aug 29, 2011, 23:09 UTC
Message-ID
<7vk49v4xyd.fsf@alter.siamese.dyndns.org>
In-Reply-To
<c8d8686c1813885a36d8f4cada218686989df236.1314651926.git.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> So make sure that strbuf_grow() puts in a nul even if it has nowhere
> to copy it from.  This makes strbuf_grow(sb, 0) a semantic no-op as
> far as readers of the buffer are concerned.
Makes sense, thanks.
> Also remove the nul-termination added by strbuf_init, which is made
> redudant.
Ok.

This is a tangent but if we do not have hint, we point at strbuf_slopbuf[] which is:

    /*
     * Used as the default ->buf value, so that people can always assume
     * buf is non NULL and ->buf is NUL terminated even for a freshly
     * initialized strbuf.
     */
    char strbuf_slopbuf[1];

While nobody should be writing into it, we do not really enforce the constness of this buffer.

I wonder if it would be worth making this into "const char []" and have the complier/linker move it to read-only section to catch potential bugs.

Previous: Erik Faye-LundNext: Brandon Casey
Message 3 of 4 in “strbuf_grow(): maintain nul-termination even for new buffer”
  1. strbuf_grow(): maintain nul-termination even for new bufferThomas Rast, Aug 29, 2011
  2. Erik Faye-LundAug 29, 2011
  3. Junio C HamanoAug 29, 2011
  4. Brandon CaseyAug 29, 2011

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.