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

[Erick Mattos <erick.mattos@gmail.com>]

Hi,

We are becoming a little theoretical here so people please be
condescending to us if the chat gets a little boring.  ;-)

2010/6/10 Thomas Rast <trast@student.ethz.ch>:
> 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.

Not really.

What the actual log_ref_setup() does when is instantiated is to create
a pointer in the stack, called log_file, to a pointer to a char array.
 This pointer receives the address of a char array of the calling
function because that is why passing by reference is made to.  See
that the calling functions is using the "&" when making the call (If I
was using C++ I would pass by reference the array itself but in C I
can only pass pointer variables by reference that is why the pointer
to a pointer).

Then git_snpath() creates a char array in the heap with the right
content and changes the stack pointer logfile to it.  Then when we do
*log_file = logfile what is happening is that the content of the
pointer in the stack, log_file, which its content is the calling
function char array pointer, is being set to the address of the buffer
created in the heap by git_snpath().  After it, what you have is just
the natural cleanup of the stack variables of the called function but
the calling variable keeps the address of the char array in the heap
created by git_snpath().

> 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).

That is another thing.

>> 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).

I don't think I am good enough too.  I have always things to learn.
And I hopefully will be always learning new things!  I am addicted to
it.  :-S

Everybody is here to help each other and NOBODY does not commit
mistakes so your help is very welcome but don't deposit all your
beliefs in any piece of software because all of them could contain
mistakes too, even if the best ever existent programmers had made them
in whole.

Programming is teaching a limited dumb equipment to be clever.  So it
is in itself a contradiction.

Best regards