difficulty in using malloc for 2D array when outside the main function

HI please help me here. Segmentation fault always occur in my program. when malloc is in main, it is running, but when i put malloc in another function, segmentation fault occurs. here is my code

Code:

#include<stdio.h>
#include<malloc.h>

void malloc_array(int **array;int row;int col){

	int i;
	
	array=(int**)malloc(row*sizeof(int*));
	for(i=0;i<row;i++){
		array[i]=(int*)malloc(col*sizeof(int);
	}
}

main(){
	int **array, row=5, col=7;
	
	malloc_array(array,row,col);

      .
      .
      .
}

You should be returning the array variable. You get the segmentation fault because you've leaked the memory allocated by malloc when this function returns, and the pointers are invalidated. Think about how malloc works. It also returns allocated pointers: when you roll your own allocation functions, they should behave the same way.

That code won't even compile, let alone give a segmentation fault. As a rough rule, it is better to post ACTUAL functional code in forums (for example, cut and paste from an actual source file) than it is to try to paraphase ot to type it in from memory. You have not posted actual code, so have mucked up, big time.

However, if you want to pass a "pointer to pointer" to a function, and have any changes made visible to the caller, you have to pass a "pointer to pointer to pointer". For example (count the asterixes and ampersands carefully)

Code:

#include<stdio.h>
#include<malloc.h>

void malloc_array(int ***array,int row,int col)
{
	int i;
	
	*array=malloc(row*sizeof(int*));
	for(i=0;i<row;i++){
		(*array)[i]=malloc(col*sizeof(int));
	}
}

int main()
{
	int **array, row=5, col=7;
	
	malloc_array(&array,row,col);

         /*   You can now use array here without getting in danger */
}

Incidentally, it is considered bad style to rely on the "implicit int" return type (and such things are deprecated). If a function returns int, write it that way. In C, you should not need to have a type conversion on the return value from malloc().

Not to mention...

void malloc_array(int ***array;int row;int col)

Shouldn't the original code give a warning about an uninitialised variable?
The pointer is being passed in by value but has never been made to point to anything.

Originally Posted by grumpy

That code won't even compile, let alone give a segmentation fault. As a rough rule, it is better to post ACTUAL functional code in forums (for example, cut and paste from an actual source file) than it is to try to paraphase ot to type it in from memory. You have not posted actual code, so have mucked up, big time.

However, if you want to pass a "pointer to pointer" to a function, and have any changes made visible to the caller, you have to pass a "pointer to pointer to pointer". For example (count the asterixes and ampersands carefully)

Code:

#include<stdio.h>
#include<malloc.h>

void malloc_array(int ***array,int row,int col)
{
	int i;
	
	*array=malloc(row*sizeof(int*));
	for(i=0;i<row;i++){
		(*array)[i]=malloc(col*sizeof(int));
	}
}

int main()
{
	int **array, row=5, col=7;
	
	malloc_array(&array,row,col);

         /*   You can now use array here without getting in danger */
}

Incidentally, it is considered bad style to rely on the "implicit int" return type (and such things are deprecated). If a function returns int, write it that way. In C, you should not need to have a type conversion on the return value from malloc().

thank you for your answer, this is my first post here so i am not really sure of what i'm doing. thank you.

Originally Posted by iMalc

Shouldn't the original code give a warning about an uninitialised variable?
The pointer is being passed in by value but has never been made to point to anything.

There is no "should" (or "shouldn't") about it.

Accessing the value of any uninitialised variable, according to the standard, gives undefined behaviour (and "pass by value" is so-named because it accessed the value in order to pass it). That means there is no requirement for a compiler diagnostic, no requirement for sensible runtime behaviour, no requirement for a run time error, and no requirement for anything else.

In practice, warning about uninitialised variables is generally considered a quality-of-implementation concern for the compiler - as is anything normally categorised as a "warning". Good quality compilers are often able to detect and report cases of uninitialised variables. However, other than programmer expectations and willingness of vendors to satisfy them, there is no force that ensures any compiler will report uninitialised variables.

Most compilers with capability to report uninitialised variables disable that feature by default. There are various reasons, both good and bad, for that state of affairs. It is therefore necessary, with those compilers, to activate higher levels of warning (for example, by command line switches).

[Personally, I consider any programmer worth their salt will activate the maximum warning levels for every compiler they use]

Originally Posted by grumpy

However, if you want to pass a "pointer to pointer" to a function, and have any changes made visible to the caller, you have to pass a "pointer to pointer to pointer". For example (count the asterixes and ampersands carefully)

Rather than be a three star programmer, consider wrapping your 2D array in a struct that could well include the row and col variables. Even if you do not ever pass a pointer to this struct to a function, it can still be helpful as an abstraction.