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

Re: [PATCH next v2] log_ref_setup: don't return stack-allocated array

From
Thomas Rast <trast@student.ethz.ch>
Date
Jun 10, 2010, 17:29 UTC
Message-ID
<201006101929.11034.trast@student.ethz.ch>
In-Reply-To
<AANLkTillDOCNQrpaEiFsFdq6HpU_LlwWI2ELIrEcrWHc@mail.gmail.com>
Erick Mattos wrote:
Show 10 quoted lines
> 2010/6/10 Thomas Rast <trast@student.ethz.ch>
> > -int log_ref_setup(const char *ref_name, char **log_file)
> > +int log_ref_setup(const char *ref_name, char *logfile, int bufsize)
> >  {
> >        int logfd, oflags = O_APPEND | O_WRONLY;
> > -       char logfile[PATH_MAX];
> >
> > -       git_snpath(logfile, sizeof(logfile), "logs/%s", ref_name);
> > -       *log_file = logfile;
> > +       git_snpath(logfile, bufsize, "logs/%s", ref_name);
[...]
Show 5 quoted lines
> I don't see any improvement here.  Unless you want to get rid of using
> references on calling functions which is only going to add another
> buffer to the stack, sized PATH_MAX, once that log_file is going to be
> really allocated in the heap after git_snpath().  As folks use to say
> here: "changing six by half a dozen".

What the - side of the hunk above does is returning a local (stack allocated) variable, in the form of a pointer to logfile. Once those go out of scope, you have zero guarantees on what happens with them. Try the following snippet, it should cause a similar problem:

  #include <stdio.h>
  int* f()
  {
  	int i;
  	i = 42;
  	return &i;
  }
  int main()
  {
  	int *p = f();
  	if (1) {
  		char buf[1024];
  		memset(buf, 0, sizeof(buf));
  	}
  	printf("I got: %d\n", *p);
  }

Only in this case the issue is so obvious that the compiler will warn (at least mine does).

> I haven't ever seen this happening so I think you have found some
> particularity of valgrind which could route a patch to it.

Admittedly my experience is somewhat limited since I don't do C coding outside of git and some teaching. But so far I have not had a single false alarm with valgrind (when compiled without optimizations; otherwise the compiler may do some magic).

-- 
Thomas Rast
trast@{inf,student}.ethz.ch
Previous: Erick MattosNext: Erick Mattos
Message 4 of 11 in “log_ref_setup: don't return stack-allocated array”
  1. log_ref_setup: don't return stack-allocated arrayThomas Rast, Jun 10, 2010
  2. log_ref_setup: don't return stack-allocated arrayThomas Rast, Jun 10, 2010
  3. Erick MattosJun 10, 2010
  4. Thomas RastJun 10, 2010
  5. Erick MattosJun 10, 2010
  6. Jeff KingJun 11, 2010
  7. Erick MattosJun 11, 2010
  8. Ævar Arnfjörð BjarmasonJun 10, 2010
  9. check_aliased_update: strcpy() instead of strcat() to copyThomas Rast, Jun 10, 2010
  10. Ævar Arnfjörð BjarmasonJun 10, 2010
  11. Jay SoffianJun 10, 2010

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.