C - Good use of pointers?

Author

Good use of pointers?

Johs32

2006-02-23, 6:56 pm

I am a bit uncertain that this is a good use of pointers:

int *ip[10];
ip[0] = malloc(sizeof(int));
*ip[0] = 22;

Is there any problems with this declaration and would it survive a function
that returns, if I make the function return a pointer to an int??

Antonio Contreras

2006-02-23, 6:56 pm

Johs32 wrote:
> I am a bit uncertain that this is a good use of pointers:
>
> int *ip[10];
> ip[0] = malloc(sizeof(int));
> *ip[0] = 22;
>
> Is there any problems with this declaration?

No

and would it survive a function
> that returns, if I make the function return a pointer to an int??

If you enclose the three lines in a function body, the array will cease
to exist at the moment the function exits. If you return some of the
values of the array you may capture them in the caller, but the other 9
pointers will be lost. If you want to retain all ten pointer you should
malloc space for the array and return the address of the array as an
int**. (There are other possibilities, but this is the simplest IMO).

Andrey Tarasevich

2006-02-23, 6:56 pm

Johs32 wrote:
> I am a bit uncertain that this is a good use of pointers:
>
> int *ip[10];
> ip[0] = malloc(sizeof(int));
> *ip[0] = 22;

It is impossible to decide whether this is a "good" or "bad" use from such an
abstract example, without context. There's nothing immediately illegal in this
code, that's all that can be said.

> Is there any problems with this declaration

Declaration? The very first line is a declaration, the rest are not. The
declaration looks fine. Whether there are any problems with the whole thing
depends on what it is you are trying to do.

> and would it survive a function
> that returns, if I make the function return a pointer to an int??

Could you, please, clarify, _what_ exactly should survive? You declare an object
of type 'int*[10]', which cannot serve as a return value for a function that
"returns a pointer to an int" - the types are different. If you are planning to
return 'ip[0]' then everything will... hm... "survive", if I understand your
"survive" correctly.

--
Best regards,
Andrey Tarasevich

Sirius Black

2006-02-23, 9:55 pm

Antonio Contreras wrote:
> Johs32 wrote:
>
>
>
> No

Except that you are not checking the ptr returned by malloc. You should
check if malloc succeeded or not and then only use the memory allocated.

>
> and would it survive a function
>
>
>
> If you enclose the three lines in a function body, the array will cease
> to exist at the moment the function exits. If you return some of the
> values of the array you may capture them in the caller, but the other 9
> pointers will be lost. If you want to retain all ten pointer you should
> malloc space for the array and return the address of the array as an
> int**. (There are other possibilities, but this is the simplest IMO).
>

weaselboy1976

2006-02-24, 6:55 pm

So, if you are looking to do something like:

int* someFunction()
{
int *ip[10];
ip[0] = malloc(sizeof(int));
*ip[0] = 22;
return ip[0];
}

The value 22 would "survive". But this is really bad form. You should
always do malloc and free within the same scope, not in different
functions. Also, it's a good idea to always make your functions return
an int that represents an error code. So something like this would be
much better:

int functionOne()
{
int i;
int *ip[10];
for (i=0; i<10; i++)
{
*ip[i] = NULL;
}
ip[0] = malloc(sizeof(int));
if (ip[0] == (int)0)
return 1; /*error, allocation not done*/
if (functionTwo(ip[0])
return 2; /*error is functionTwo*/
if (*ip[0] != NULL)
{
free(ip[0];
*ip[0] = NULL;
}
return 0;
}

int functionTwo(int *ip)
{
*ip = 22;
return 0;
}

Clark S. Cox III

2006-02-24, 6:56 pm

On 2006-02-24 09:12:45 -0500, "weaselboy1976" <weaselboy1976@yahoo.com> said:

> So, if you are looking to do something like:
>
> int* someFunction()
> {
> int *ip[10];
> ip[0] = malloc(sizeof(int));
> *ip[0] = 22;
> return ip[0];
> }
>
> The value 22 would "survive". But this is really bad form. You should
> always do malloc and free within the same scope, not in different
> functions.

"Always" is a bit strong there. I'd bet that more often than not, the
malloc and free should be in different functions; otherwise, you've
done nothing but emulate automatic variables.

> Also, it's a good idea to always make your functions return
> an int that represents an error code.

Again, "Always" is a bit strong.

--
Clark S. Cox, III
clarkcox3@gmail.com

pete

2006-02-24, 6:56 pm

Clark S. Cox III wrote:
>
> On 2006-02-24 09:12:45 -0500, "weaselboy1976" <weaselboy1976@yahoo.com> said:
>
>
> "Always" is a bit strong there. I'd bet that more often than not, the
> malloc and free should be in different functions; otherwise, you've
> done nothing but emulate automatic variables.

It is a bit strong.
Linked lists are simplest to free with a list freeing function,
rather than from where the nodes were allocated.

--
pete

Richard G. Riley

2006-02-24, 6:56 pm

On 2006-02-24, weaselboy1976 <weaselboy1976@yahoo.com> wrote:
> So, if you are looking to do something like:
>
> int* someFunction()
> {
> int *ip[10];
> ip[0] = malloc(sizeof(int));
> *ip[0] = 22;
> return ip[0];
> }
>
> The value 22 would "survive". But this is really bad form. You should
> always do malloc and free within the same scope, not in different
> functions. Also, it's a good idea to always make your functions return
> an int that represents an error code. So something like this would be
> much better:
>

This is not true. Sorry.

In any system of any size, memory allocations are frequently handled
in an optimised system memory handler. In addition the creation of an
object in the system does not immediatley mean that good prorgamming
practices insist that that same function also destroys it. A good example
might be a message based window system : the code with creates the
window/dialog is never (almost) responsible for deleting it. A system
dealing with Business Objects based on a database. Lots of things.

malloc is not immitiating an automatic stack variable and it not
intended to. That said, if using malloc to create a temporary buffer,
of course it makes sense to clean up in the same scope as it was
created if it is no further needed

stathis gotsis

2006-02-24, 6:56 pm

"weaselboy1976" <weaselboy1976@yahoo.com> wrote in message
news:1140790365.434657.255330@v46g2000cwv.googlegroups.com...
> So, if you are looking to do something like:
>
> int* someFunction()
> {
> int *ip[10];
> ip[0] = malloc(sizeof(int));
> *ip[0] = 22;
> return ip[0];
> }
>
> The value 22 would "survive". But this is really bad form. You should
> always do malloc and free within the same scope, not in different
> functions. Also, it's a good idea to always make your functions return
> an int that represents an error code. So something like this would be
> much better:
>
> int functionOne()
> {
> int i;
> int *ip[10];
> for (i=0; i<10; i++)
> {
> *ip[i] = NULL;

ip[i] = NULL;

> }
> ip[0] = malloc(sizeof(int));
> if (ip[0] == (int)0)
> return 1; /*error, allocation not done*/
> if (functionTwo(ip[0])

Syntax error.

> return 2; /*error is functionTwo*/
> if (*ip[0] != NULL)

ip[0] != NULL

> {
> free(ip[0];

Syntax error.

> *ip[0] = NULL;
> }
> return 0;
> }
>
> int functionTwo(int *ip)
> {
> *ip = 22;
> return 0;
> }
>

Andrey Tarasevich

2006-02-27, 3:56 am

weaselboy1976 wrote:
> ...
> The value 22 would "survive". But this is really bad form. You should
> always do malloc and free within the same scope, not in different
> functions.
> ...

No. Absolutely not. This is one of those "fake" rules that sound "true" but in
fact make no sense at all.

There are several reason to use freestore in the program (as opposed to using
static and automatic storage) and one of the most important ones is that
freestore allows the user to extend the lifetime of the object beyond the bounds
dictated by the scoping rules.

--
Best regards,
Andrey Tarasevich

Sponsored Links