Thread: Uninitialised value was created by a stack allocation --geting desperate!

Post the code of the smallest and simplest compilable program based on your program for which Valgrind complains about this.

I'm only guessing here, but it looks to me like you're using test_num to tell my_method how many elements are pointed to by test_struct. If that is the case, then I'd say that this program is dangerous, because do_something is modifying test_num before you pass it to my_method, but after you allocate the array. Changing the value of test_num does not change the size of the array that has already been allocated. It's not as if you're assigning a formula to test_struct, where modifying its inputs implicitly modifies its outputs. It happens in sequence. On line 5, the array is allocated. Nothing you do after that can change its size, short of freeing the memory and allocating new. These things must be done explicitly.

Dunno, if it is true then the Valgrind message sounds misleading since it says "Uninitialised value was created by a stack allocation" (emphasis mine).

EDIT:

Originally Posted by Elkvis

Nothing you do after that can change its size, short of freeing the memory and allocating new.

realloc does not necessarily free the memory and allocate it anew.

I asked for a complete program because then we can be sure that you aren't leaving out something that you didn't think was important. For example, get Valgrind to comment about this program:

Code:

#include <stdio.h>
#include <stdlib.h>

typedef struct test_
{
    int n;
} test;

void do_something(int *x)
{
    ++*x;
}

void my_method(test *array_struct, int test_num)
{
    printf("%p %d\n", (void*)array_struct, test_num);
}

int main(void)
{
    test *test_struct;
    int test_num = 2;
    /*my structure test is just an array with two entries*/
    test_struct = malloc(sizeof(test) * test_num);

    /*now I change the the test_num by a method, but it is 100% always >0, the method just increases the number*/
    do_something(&test_num);

    /*Now I call my method, where I give a copy of test_num as a parameter*/
    my_method(test_struct, test_num);

    free(test_struct);
    return 0;
}

According to what you described in post #1, Valgrind should be reporting the same problem, but I doubt it will.

Originally Posted by laserlight

realloc does not necessarily free the memory and allocate it anew.

True enough, but conceptually, it has the same effect.

Originally Posted by tinchi

Yes you are right, I forgot to mention in the first post that the first method also gets an instance of the array and of course reallocates and changes it!

We can see this in your updated code snippet for do_something, but you obviously didn't compile it: the number of arguments to realloc is incorrect. Therefore, how do we know that your code snippet has anything at all to do with the problem reported by Valgrind? For all we know, when you edited the code, you also removed the problem, so all we are looking at is code that does not exhibit the problem. That's futile.

Code:

#include <stdlib.h>     // malloc, free
#include <stdio.h>      // printf
#include <assert.h>     // assert


#define SIZE(x) (sizeof(x)/sizeof(x[0]))
#define NEW(x) ((x)malloc(sizeof(struct x)))


typedef struct Point {
    int x;
    int y;
} *Point;


void Point_Update(Point const p, const int new_x, const new_y)
{
    p->x = new_x;
    p->y = new_y;
}


Point Point_New(const int init_x, const int init_y)
{
    Point new = NEW(Point);
    assert(new);
    Point_Update(new, init_x, init_y);
    return new;
}


void Point_Delete(const Point const point)
{
    free(point);
}


void Point_Print(const Point const point)
{
    printf("x = %d, y = %d\n", point->x, point->y);
}


Point Point_Search(const Point* arr, unsigned int siz, const int sum)
{
    Point p;
    while( siz-- ) {
        p = *arr++;
        if( p->x + p->y == sum ) { return p; }
    }
    return NULL;
}


int main(void)
{
    Point points[3] = {
        Point_New(1, 2),
        Point_New(1, 99),
        Point_New(100, 2)
    };


    Point found = Point_Search(points, SIZE(points), 100);
    if( found ) { Point_Update(found, 0, 100); }


    unsigned int i;
    for( i = 0; i < SIZE(points); ++i ) {
        Point_Print(points[i]);
        Point_Delete(points[i]);
    }
    return 0;
}

Originally Posted by zub

Code:

void Point_Print(const Point const point)
{
    printf("x = %d, y = %d\n", point->x, point->y);
}

You do realise that a typedef is not a macro, right? You probably had a declaration equivalent to this in mind:

Code:

void Point_Print(const struct Point* const point)
{
    printf("x = %d, y = %d\n", point->x, point->y);
}

in which case not only is the pointer named point declared const, but also what it points to. However, because you used the typedef name Point instead, having the keyword const on both sides of the type name is superfluous: either way, only the pointer named point is declared const: what it points to is still declared non-const.

This demonstrates yet again that the practice of having pointer typedefs for non-opaque pointer types is a poor practice.

Thank you for being enlightened, you are certainly right about my assumptions. I do not know much yet in such nuances.

This demonstrates yet again that the practice of having pointer typedefs for non-opaque pointer types is a poor practice.

I think this style have rights to exist in some kinds of programs. Perhaps it does have its flaws, but it can be said about any style. For example, I'm writing a program that initially wanted to build in this style. It turned out that it is redundant. Instead, I did support for arrays, orgranized similar to C-strings (some special number signals the end of the array). That was enough to make program incredibly simple and clear.