function to return pointer question

**Default User** · Jan 11 '07, 11:55 PM

Re: function to return pointer question

Andrew Gentile wrote:

Hello,
I have been working on a program where I need to have a function
return an array. I found out that C doesn't do this, so now I am
trying to get the function to return a pointer to an array. It seems
easy, but I keep running into the same problem. The function appears
to execute properly, but when I print out the array values, only the
first one is correct. The other are all wrong. A snippet of code is
below. Please take a look and see what I have done wrong. Thank you
in advance for your help.

In the future, please post EXACT code. Cut and paste. I can tell you
didn't because this is all screwed up and wouldn't have compiled.

void main(void)

main() returns int, ALWAYS. You're also missing then opening brace (and
the closing braces it would appear.

int *point(int); // function proto
int *p, i,count;
i=0;
count=5;
>
p=point(count); // call function, p should be value at array x2[0]
>
for(i=0;i<count ;i++) // print out array
>
{
printf("\nfunct ion retun = %i",*p);
p++;
}
}
>
>
int *point(int k) // function to create array k-1 integers long.
{
int *p2,x2[k],i2;
i2=0;
while(i2<k)
{
x2[i2]=3*k;
i2++;
}
p2=x2;

You've set p2 to point to the start of an automatic array, which will
go out of scope as soon as the function returns. You can't do that.

return p2;
}

Either dynamically allocate the array in point() using malloc() or
friends, or pass in the array from the calling function.

Brian

**Richard** · Jan 12 '07, 12:25 AM

Re: function to return pointer question

"Andrew Gentile" <andrewkgentile @gmail.comwrite s:

Hello,
I have been working on a program where I need to have a function
return an array. I found out that C doesn't do this, so now I am

The only type not strictly passed by value. A pointer to the array is
passed. Its a C thing.

With regards to your problem : Look at your local variable x2 in
function point(). A local will be effectively destroyed when you return
from the function which declared it.

Look into using malloc.

best of luck!

trying to get the function to return a pointer to an array. It seems
easy, but I keep running into the same problem. The function appears
to execute properly, but when I print out the array values, only the
first one is correct. The other are all wrong. A snippet of code is
below. Please take a look and see what I have done wrong. Thank you
in advance for your help.
>
void main(void)
int *point(int); // function proto
int *p, i,count;
i=0;
count=5;
>
p=point(count); // call function, p should be value at array x2[0]
>
for(i=0;i<count ;i++) // print out array
>
{
printf("\nfunct ion retun = %i",*p);
p++;
}
}
>
>
int *point(int k) // function to create array k-1 integers long.
{
int *p2,x2[k],i2;
i2=0;
while(i2<k)
{
x2[i2]=3*k;
i2++;
}
p2=x2;
return p2;
}
>

--

**Richard Heathfield** · Jan 12 '07, 12:55 AM

Re: function to return pointer question

Richard said:

"Andrew Gentile" <andrewkgentile @gmail.comwrite s:
>

>Hello,
> I have been working on a program where I need to have a function
>return an array. I found out that C doesn't do this, so now I am

>
The only type not strictly passed by value.

Types aren't passed. Values are passed, and values have types. The value of
an array (that is, what you get when you use an array name in an expression
where it is not the operand of & or sizeof) is a pointer to its first
element.

A pointer to the array is passed.

No, a pointer to the array's first element is passed. This is the difference
between T * and T (*)[N].

And since the OP's program didn't even attempt to pass an array, I don't see
which point it is, precisely, that you are failing to make.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999

http://www.cpax.org.uk

email: rjh at the above domain, - www.

**Richard** · Jan 12 '07, 01:15 AM

Re: function to return pointer question

Richard Heathfield <rjh@see.sig.in validwrites:

Richard said:
>

>"Andrew Gentile" <andrewkgentile @gmail.comwrite s:
>>

>>Hello,
>> I have been working on a program where I need to have a function
>>return an array. I found out that C doesn't do this, so now I am

>>
>The only type not strictly passed by value.

>
Types aren't passed. Values are passed, and values have types. The
value of

Give me a break.

It makes perfect sense in the C context.

an array (that is, what you get when you use an array name in an expression
where it is not the operand of & or sizeof) is a pointer to its first
element.
>

>A pointer to the array is passed.

>
No, a pointer to the array's first element is passed. This is the difference
between T * and T (*)[N].

Correct. Q : when is a pointer to an array NOT the same value as a
pointer to the first element of an arry?

>
And since the OP's program didn't even attempt to pass an array, I don't see
which point it is, precisely, that you are failing to make.

If you were to READ the OP then you would know to what I was referring.

You also snipped my reply to the actual PROBLEM he had.

--

**Keith Thompson** · Jan 12 '07, 01:25 AM

Re: function to return pointer question

Richard Heathfield <rjh@see.sig.in validwrites:

Richard said:

>"Andrew Gentile" <andrewkgentile @gmail.comwrite s:
>>

>>Hello,
>> I have been working on a program where I need to have a function
>>return an array. I found out that C doesn't do this, so now I am

>>
>The only type not strictly passed by value.

>
Types aren't passed. Values are passed, and values have types. The value of
an array (that is, what you get when you use an array name in an expression
where it is not the operand of & or sizeof) is a pointer to its first
element.

[...]

Your overall point is (unsurprisingly ) correct, but I'm going to
quibble about the wording.

It's certainly true that "what you get when you use an array name in
an expression where it is not the operand of & or sizeof" is a pointer
to the array's first element. However, that's not what "the value of
an array" is. The value of an array ("array" here means "array
object") is the value of the array object itself, consisting of the
values of its elements.

When an array object's name is used as an expression (that is not the
operand of unary "&" or "sizeof"), the result of the expression is the
address of the array's first element; this is not the "value of the
array".

Incidentally while writing this I looked up the standard's definition
of "value" (C99 3.17):

precise meaning of the contents of an object when interpreted as
having a specific type

That would seem to imply that an expression such as 42, that doesn't
refer to any object, does not yield a "value". I've always thought of
a "value" as being either the interpreted contents of an object *or*
the result of an expression.

But the definition of "expression " (C99 6.5p1) is:

a sequence of operators and operands that specifies computation of
a value, or that designates an object or a function, or that
generates side effects, or that performs a combination thereof.

This isn't a big deal, just a bit of sloppy wording in the standard's
definitions.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

**Richard Heathfield** · Jan 12 '07, 01:45 AM

Re: function to return pointer question

Richard said:

Richard Heathfield <rjh@see.sig.in validwrites:

>Richard said:

>>"Andrew Gentile" <andrewkgentile @gmail.comwrite s:
>>>
>>>Hello,
>>> I have been working on a program where I need to have a function
>>>return an array. I found out that C doesn't do this, so now I am
>>>
>>The only type not strictly passed by value.

>>
>Types aren't passed. Values are passed, and values have types. The
>value of

>
Give me a break.

First give me a switch.

It makes perfect sense in the C context.

No, it makes no sense at all in the C context.

>an array (that is, what you get when you use an array name in an
>expression where it is not the operand of & or sizeof) is a pointer to
>its first element.
>>

>>A pointer to the array is passed.

>>
>No, a pointer to the array's first element is passed. This is the
>difference between T * and T (*)[N].

>
Correct. Q : when is a pointer to an array NOT the same value as a
pointer to the first element of an arry?

Always, because values have types, and a pointer to an array has a different
type to a pointer to the first element of that array.

>And since the OP's program didn't even attempt to pass an array, I don't
>see which point it is, precisely, that you are failing to make.

>
If you were to READ the OP then you would know to what I was referring.

I did read the OP, and I still don't know to what your reply referred.

You also snipped my reply to the actual PROBLEM he had.

Yes, I did, and I don't think anything important was lost thereby.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999

http://www.cpax.org.uk

email: rjh at the above domain, - www.

**Richard Heathfield** · Jan 12 '07, 01:55 AM

Re: function to return pointer question

Keith Thompson said:

Richard Heathfield <rjh@see.sig.in validwrites:

>Richard said:

>>"Andrew Gentile" <andrewkgentile @gmail.comwrite s:
>>>
>>>Hello,
>>> I have been working on a program where I need to have a function
>>>return an array. I found out that C doesn't do this, so now I am
>>>
>>The only type not strictly passed by value.

>>
>Types aren't passed. Values are passed, and values have types. The value
>of an array (that is, what you get when you use an array name in an
>expression where it is not the operand of & or sizeof) is a pointer to
>its first element.

[...]
>
Your overall point is (unsurprisingly ) correct, but I'm going to
quibble about the wording.

Yes, I can understand why. Trying to get the wording precisely correct on
this matter can be a bit of a struggle, and I accept the quibble. My
parenthesised comment was meant to clarify the concept I was aiming at (the
- um - "entity" you get when you use an array name in an expression where
it is not an operand of sizeof or &), but I can see how it didn't achieve
that objective terribly well.

<snip>

Incidentally while writing this I looked up the standard's definition
of "value" (C99 3.17):
>
precise meaning of the contents of an object when interpreted as
having a specific type
>
That would seem to imply that an expression such as 42, that doesn't
refer to any object, does not yield a "value". I've always thought of
a "value" as being either the interpreted contents of an object *or*
the result of an expression.

Yes, and both the C89 Standard and the C99 Standard refer to "the value of
CHAR_MIN" when describing numerical limits, even though it is quite evident
that CHAR_MIN is not an object. So, one way or another, the C99 Standard is
wrong.

<snip>

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999

http://www.cpax.org.uk

email: rjh at the above domain, - www.

**Richard Heathfield** · Jan 12 '07, 01:55 AM

Re: function to return pointer question

Keith Thompson said:

Richard Heathfield <rjh@see.sig.in validwrites:

>Richard said:

>>"Andrew Gentile" <andrewkgentile @gmail.comwrite s:
>>>
>>>Hello,
>>> I have been working on a program where I need to have a function
>>>return an array. I found out that C doesn't do this, so now I am
>>>
>>The only type not strictly passed by value.

>>
>Types aren't passed. Values are passed, and values have types. The value
>of an array (that is, what you get when you use an array name in an
>expression where it is not the operand of & or sizeof) is a pointer to
>its first element.

[...]
>
Your overall point is (unsurprisingly ) correct, but I'm going to
quibble about the wording.

Yes, I can understand why. Trying to get the wording precisely correct on
this matter can be a bit of a struggle, and I accept the quibble. My
parenthesised comment was meant to clarify the concept I was aiming at (the
- um - "entity" you get when you use an array name in an expression where
it is not an operand of sizeof or &), but I can see how it didn't achieve
that objective terribly well.

<snip>

Incidentally while writing this I looked up the standard's definition
of "value" (C99 3.17):
>
precise meaning of the contents of an object when interpreted as
having a specific type
>
That would seem to imply that an expression such as 42, that doesn't
refer to any object, does not yield a "value". I've always thought of
a "value" as being either the interpreted contents of an object *or*
the result of an expression.

Yes, and both the C89 Standard and the C99 Standard refer to "the value of
CHAR_MIN" when describing numerical limits, even though it is quite evident
that CHAR_MIN is not an object. So, one way or another, the C99 Standard is
wrong.

<snip>

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999

http://www.cpax.org.uk

email: rjh at the above domain, - www.

**Barry Schwarz** · Jan 12 '07, 02:35 AM

Re: function to return pointer question

On 11 Jan 2007 15:31:07 -0800, "Andrew Gentile"
<andrewkgentile @gmail.comwrote :

>Hello,
I have been working on a program where I need to have a function
>return an array. I found out that C doesn't do this, so now I am
>trying to get the function to return a pointer to an array. It seems
>easy, but I keep running into the same problem. The function appears
>to execute properly, but when I print out the array values, only the
>first one is correct. The other are all wrong. A snippet of code is
>below. Please take a look and see what I have done wrong. Thank you
>in advance for your help.
>

snip a very broken main

>
>
>int *point(int k) // function to create array k-1 integers long.
>{
>int *p2,x2[k],i2;
>i2=0;
>while(i2<k)
> {
> x2[i2]=3*k;
> i2++;
> }
>p2=x2;
>return p2;
>}

Your are returning the address of an automatic array that will go out
of existence as soon as you leave the function. Any attempt to use or
evaluate that address after point terminates invokes undefined
behavior. Three ways come to mind to prevent the array from
disappearing on you:

Declare it as static. Static objects are guaranteed to exist for
the duration of your program. This can cause problems if you call the
function twice and expect to be able to use both results
simultaneously.

Allocate it dynamically. Dynamic memory remains available until
you deliberately free it.

Define the array in the calling program and pass it to the called
function. The called function can update the array directly so
returning its address is a decision based on other design
considerations.

Remove del for email

**Andrew Gentile** · Jan 12 '07, 02:45 PM

Re: function to return pointer question

Thanks. I got it. The array is destroyed once the function is done
executing. This is why the first value of the array remains, because
it is stored with the pointer. So, if I declared my array as a global
variable, this would fix the problem. thanks again.

Andrew

Richard wrote:

"Andrew Gentile" <andrewkgentile @gmail.comwrite s:
>

Hello,
I have been working on a program where I need to have a function
return an array. I found out that C doesn't do this, so now I am

>
The only type not strictly passed by value. A pointer to the array is
passed. Its a C thing.
>
With regards to your problem : Look at your local variable x2 in
function point(). A local will be effectively destroyed when you return
from the function which declared it.
>
Look into using malloc.
>
best of luck!
>

trying to get the function to return a pointer to an array. It seems
easy, but I keep running into the same problem. The function appears
to execute properly, but when I print out the array values, only the
first one is correct. The other are all wrong. A snippet of code is
below. Please take a look and see what I have done wrong. Thank you
in advance for your help.

void main(void)
int *point(int); // function proto
int *p, i,count;
i=0;
count=5;

p=point(count); // call function, p should be value at array x2[0]

for(i=0;i<count ;i++) // print out array

{
printf("\nfunct ion retun = %i",*p);
p++;
}
}

int *point(int k) // function to create array k-1 integers long.
{
int *p2,x2[k],i2;
i2=0;
while(i2<k)
{
x2[i2]=3*k;
i2++;
}
p2=x2;
return p2;
}

>
--

**Richard Heathfield** · Jan 12 '07, 04:15 PM

Re: function to return pointer question

Andrew Gentile said:

Thanks. I got it. The array is destroyed once the function is done
executing. This is why the first value of the array remains, because
it is stored with the pointer.

No, it isn't. The pointer stores only a pointer value. In terms of the
abstract machine, the array is destroyed and the pointer value is
indeterminate. In practical terms, however, it is often the case that the
values you stored in the array may still be hanging around at the location
where it once existed. Nevertheless, a wise programmer will not rely on
this very unreliable behaviour, especially since those values could be
overwritten at any time.

So, if I declared my array as a global
variable, this would fix the problem.

It would, however, cause you other problems.

Either (a) create a large-enough array before calling the function, and pass
a pointer to its first element as an argument to the function, or (b)
dynamically allocate the array within the function and return a pointer to
its first element.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999

http://www.cpax.org.uk

email: rjh at the above domain, - www.

**Keith Thompson** · Jan 12 '07, 09:25 PM

Re: function to return pointer question

Richard Heathfield <rjh@see.sig.in validwrites:

Andrew Gentile said:

[...]

>So, if I declared my array as a global
>variable, this would fix the problem.

>
It would, however, cause you other problems.
>
Either (a) create a large-enough array before calling the function, and pass
a pointer to its first element as an argument to the function, or (b)
dynamically allocate the array within the function and return a pointer to
its first element.

For (b), it becomes the caller's responsibility to free() the pointer to
the allocated memory.

Or (c) you can declare a *static* array within the function and return
a pointer to its first element; a static object does not cease to
exist when the function terminates. This solution has a number of
potential problems. The length is fixed; you'll probably either waste
space or not have enough. There's only one copy for all calls to the
function; if you call the function multiple times, each call can
clobber the result of the previous one. There are actually some
functions in the standard C library that use this approach; see
asctime(), for example.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

**Ark** · Jan 14 '07, 06:25 AM

Re: function to return pointer question

Richard Heathfield wrote:

Keith Thompson said:
>

<snip>

>That would seem to imply that an expression such as 42, that doesn't
>refer to any object, does not yield a "value". I've always thought of
>a "value" as being either the interpreted contents of an object *or*
>the result of an expression.

>
Yes, and both the C89 Standard and the C99 Standard refer to "the value of
CHAR_MIN" when describing numerical limits, even though it is quite evident
that CHAR_MIN is not an object. So, one way or another, the C99 Standard is
wrong.
>
<snip>
>

Assuming e.g.
#define CHAR_MIN (-128)
isn't it true that CHAR_MIN is a const object of type int and value
-128? And likewise 42U a const object of type unsigned int and value 42?
Oh, it lacks an address but so do register variables.
Am I wrong? What's an object anyway then?
In any case, 42 and CHAR_MIN are expressions, so they have a type and a
value.
Am I wrong again?

Thanks,
-Ark

**Lane Straatman** · Jan 14 '07, 07:05 AM

Re: function to return pointer question

"Richard Heathfield" <rjh@see.sig.in validwrote in message
news:bN-dnT5Jtt0_dDvYnZ 2dnUVZ8srinZ2d@ bt.com...

Keith Thompson said:

>Your overall point is (unsurprisingly ) correct, but I'm going to
>quibble about the wording.

>
Yes, I can understand why. Trying to get the wording precisely correct on
this matter can be a bit of a struggle, and I accept the quibble. My
parenthesised comment was meant to clarify the concept I was aiming at
(the
- um - "entity" you get when you use an array name in an expression where
it is not an operand of sizeof or &), but I can see how it didn't achieve
that objective terribly well.

Is the rub the nonsensical use of the word "object?"

>Incidentally while writing this I looked up the standard's definition
>of "value" (C99 3.17):
>>
> precise meaning of the contents of an object when interpreted as
> having a specific type
>>
>That would seem to imply that an expression such as 42, that doesn't
>refer to any object, does not yield a "value". I've always thought of
>a "value" as being either the interpreted contents of an object *or*
>the result of an expression.

>
Yes, and both the C89 Standard and the C99 Standard refer to "the value of
CHAR_MIN" when describing numerical limits, even though it is quite
evident
that CHAR_MIN is not an object. So, one way or another, the C99 Standard
is
wrong.

If one is not to use the word "object," what wording would you like to see?
LS

function to return pointer question

function to return pointer question

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment