doubt in USING POINTERS

[ambika]

Hello,
Am not very good with pointers in C,but I have a small doubt about
the way these pointers work..
We all know that in an array say x[5],x is gonna point to the first
element in that array(i.e)it will have the address of the first
element.In the the program below am not able to increment the value
stored in x,which is the address of the first element.Why am I not
able to do that?Afterall 1 is also a hexadecimal number then why
does adding 1 to x show me a error?
I got the message "Lvalue Required" when I complied the program.Even
if I declared x[5] as long int the same error continued.Can
someone please help me solve it out??
Thanks to all those who are gonna help me in this..
--ambika

#include<stdio.h>
void main()
{
int x[5]={1,2,3,4,5};
printf("\naddr in x:%p",x);
printf("\nnumber in the addr stored in x is:%d",*x);
x=x+1;
printf("\naddr in x after incrementation is:%p",x);
printf("\nnumber in the addr stored in x is:%d",*x);
}

[Zygmunt Krynicki]

On Sun, 21 Sep 2003 07:28:26 -0700, ambika wrote:

Hello,
Am not very good with pointers in C,but I have a small doubt about
the way these pointers work..
We all know that in an array say x[5],x is gonna point to the first
element in that array(i.e)it will have the address of the first
element.In the the program below am not able to increment the value
No, x is an array of 5 integers, not a pointer to anything. You cannot do
arithmetic on arrays. Array name usualy decays to a pointer to the first
element. Observe:

int x[5] = {1,2,3,4,5};
int *y;

y = (int*x)x + 2;

assert (*y == 3); // holds
I got the message "Lvalue Required" when I complied the program.Even
if I declared x[5] as long int the same error continued.Can
someone please help me solve it out??

That's because arrays are not lvalues

Regards

Z.

[Michael Winter]

"ambika" wrote on 21 Sept 03:

Hello,
Am not very good with pointers in C,but I have a small doubt about
the way these pointers work..
We all know that in an array say x[5],x is gonna point to the first
element in that array(i.e)it will have the address of the first
element.In the the program below am not able to increment the value
stored in x,which is the address of the first element.Why am I not
able to do that?Afterall 1 is also a hexadecimal number then why
does adding 1 to x show me a error?
I got the message "Lvalue Required" when I complied the program.Even
if I declared x[5] as long int the same error continued.Can
someone please help me solve it out??
Thanks to all those who are gonna help me in this..
--ambika

#include<stdio.h>
void main()
{
int x[5]={1,2,3,4,5};
printf("\naddr in x:%p",x);
printf("\nnumber in the addr stored in x is:%d",*x);
x=x+1;
printf("\naddr in x after incrementation is:%p",x);
printf("\nnumber in the addr stored in x is:%d",*x);
}

x isn't really a pointer here, it's an identifier for an array. True, it
does point to the first element, but you have to use it with subscripts.
There are two ways what you show above.

1) Declare x as a pointer (int *) and allocate an array of integers to it.
Now you could increment x, but it wouldn't be a good idea as you'd have to
keep track of what changes you made, or store the original address
elsewhere, so you could get back to the original address for deallocation.

2) Use a separate pointer, like so:

int x[ 5 ] = { 1, 2, 3, 4, 5 };
int *p = x;

printf("\nfirst array element:%d", *p);
p++;
printf("\nsecond array element:%d\n", *p);

Mike

--
Michael Winter
M.Winter@[no-spam]blueyonder.co.uk (remove [no-spam] to reply)

[thp]

In comp.std.c ambika <in*******@yahoo.com> wrote:
+ Hello,
+ Am not very good with pointers in C,but I have a small doubt about
+ the way these pointers work..
+ We all know that in an array say x[5],x is gonna point to the first
+ element in that array(i.e)it will have the address of the first
+ element.In the the program below am not able to increment the value
+ stored in x,which is the address of the first element.Why am I not
+ able to do that?

In the context "x = ...", as in most others, the subexpression "x" is
an pointer rvalue, whose value is the address of the first member of
the array x. So, "x = ..." is semantically incorrect, just as "3 =
...." is incorrect -- the left side of an assignment expression
requires an lvalue.

Tom Payne

[Jack Klein]

On Sun, 21 Sep 2003 14:38:54 GMT, "Zygmunt Krynicki"
<zy**@zyga.dyndns.org> wrote in comp.lang.c:

On Sun, 21 Sep 2003 07:28:26 -0700, ambika wrote:

Hello,
Am not very good with pointers in C,but I have a small doubt about
the way these pointers work..
We all know that in an array say x[5],x is gonna point to the first
element in that array(i.e)it will have the address of the first
element.In the the program below am not able to increment the value
No, x is an array of 5 integers, not a pointer to anything. You cannot do
arithmetic on arrays. Array name usualy decays to a pointer to the first
element. Observe:

int x[5] = {1,2,3,4,5};
int *y;

y = (int*x)x + 2;

Exactly what gibberish is this?
assert (*y == 3); // holds

I got the message "Lvalue Required" when I complied the program.Even
if I declared x[5] as long int the same error continued.Can
someone please help me solve it out??

That's because arrays are not lvalues

No, arrays are lvalues. They are not modifiable lvalues.

The standard does not address the quality or correctness of the
wording used in compiler diagnostics, and some compilers have text
that has been incorrect for years.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq

[Jack Klein]

On Sun, 21 Sep 2003 14:59:02 GMT, "Michael Winter"
<M.Winter@[no-spam]blueyonder.co.uk> wrote in comp.lang.c:

"ambika" wrote on 21 Sept 03:

Hello,
Am not very good with pointers in C,but I have a small doubt about
the way these pointers work..
We all know that in an array say x[5],x is gonna point to the first
element in that array(i.e)it will have the address of the first
element.In the the program below am not able to increment the value
stored in x,which is the address of the first element.Why am I not
able to do that?Afterall 1 is also a hexadecimal number then why
does adding 1 to x show me a error?
I got the message "Lvalue Required" when I complied the program.Even
if I declared x[5] as long int the same error continued.Can
someone please help me solve it out??
Thanks to all those who are gonna help me in this..
--ambika

#include<stdio.h>
void main()
{
int x[5]={1,2,3,4,5};
printf("\naddr in x:%p",x);
printf("\nnumber in the addr stored in x is:%d",*x);
x=x+1;
printf("\naddr in x after incrementation is:%p",x);
printf("\nnumber in the addr stored in x is:%d",*x);
}
x isn't really a pointer here, it's an identifier for an array. True, it
does point to the first element, but you have to use it with subscripts.
There are two ways what you show above.

When will the nonsense stop? Not only is it true that "x isn't really
a pointer here", but it is also true that "x isn't really a pointer in
any way, shape, or form, not under any circumstances".

x does not point to the first element of anything, x is the name of an
array and is an object, not a pointer at all. It does not point to
anything at all.
1) Declare x as a pointer (int *) and allocate an array of integers to it.
Now you could increment x, but it wouldn't be a good idea as you'd have to
keep track of what changes you made, or store the original address
elsewhere, so you could get back to the original address for deallocation.

2) Use a separate pointer, like so:

int x[ 5 ] = { 1, 2, 3, 4, 5 };
int *p = x;

printf("\nfirst array element:%d", *p);
p++;
printf("\nsecond array element:%d\n", *p);

Mike

The rest of your suggestions are good, but your statements about x are
just plain wrong.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq

[Zygmunt Krynicki]

On Sun, 21 Sep 2003 19:11:28 +0000, Jack Klein wrote:

y = (int*x)x + 2;
Exactly what gibberish is this?

Typo, i was in a rush... should read
int *y = (int*)x + 2;
No, arrays are lvalues. They are not modifiable lvalues.

Lvalue is something that can be placed on the left side of the assignment
operator. What is a 'not modifiable lvalue' then?

Regards

Z.

[Irrwahn Grausewitz]

"Zygmunt Krynicki" <zy**@zyga.dyndns.org> wrote:

On Sun, 21 Sep 2003 19:11:28 +0000, Jack Klein wrote:

y = (int*x)x + 2;

Exactly what gibberish is this?

Typo, i was in a rush... should read
int *y = (int*)x + 2;

No, arrays are lvalues. They are not modifiable lvalues.

Lvalue is something that can be placed on the left side of the assignment
operator. What is a 'not modifiable lvalue' then?

Something modifiable that can be placed on the left side of an
assignment operator. :)

To be more precise (quote from ISO/IEC 9899:1999):

6.3.2.1 Lvalues, arrays, and function designators

1 An lvalue is an expression with an object type or an incomplete type
other than void;53) if an lvalue does not designate an object when it is
evaluated, the behavior is undefined. When an object is said to have a
particular type, the type is specified by the lvalue used to designate
the object. A modifiable lvalue is an lvalue that does not have array
type, does not have an incomplete type, does not have a const-qualified
type, and if it is a structure or union, does not have any member
(including, recursively, any member or element of all contained
aggregates or unions) with a const-qualified type.

[...]

53) The name ‘‘lvalue’’ comes originally from the assignment expression
E1 = E2, in which the left operand E1 is required to be a (modifiable)
lvalue. It is perhaps better considered as representing an object
‘‘locator value’’.

[...]
Regards

Irrwahn
--
My other computer is a abacus.

[Jack Klein]

On Sun, 21 Sep 2003 19:43:18 GMT, "Zygmunt Krynicki"
<zy**@zyga.dyndns.org> wrote in comp.std.c:

On Sun, 21 Sep 2003 19:11:28 +0000, Jack Klein wrote:

y = (int*x)x + 2;

Exactly what gibberish is this?

Typo, i was in a rush... should read
int *y = (int*)x + 2;

No, arrays are lvalues. They are not modifiable lvalues.

Lvalue is something that can be placed on the left side of the assignment
operator. What is a 'not modifiable lvalue' then?

Regards

Z.

Your definition of an lvalue was superseded in 1989, by the original
ANSI standard. Not all lvalues can appear on the left hand side of an
assignment statement. If that were the case:

int x1; /* is an lvalue */
const int x2; /* is not an lvalue, can't be assigned to */

The definition of the term lvalue in standard C is:

========
6.3.2.1 Lvalues, arrays, and function designators

An lvalue is an expression with an object type or an incomplete type
other than void; if an lvalue does not designate an object when it is
evaluated, the behavior is undefined. When an object is said to have a
particular type, the type is specified by the lvalue used to
designate the object. A modifiable lvalue is an lvalue that does not
have array type, does not have an incomplete type, does not have a
const-qualified type, and if it is a structure or union, does not have
any member (including, recursively, any member or element of
all contained aggregates or unions) with a const-qualified type.
========

Note the specific limitations on what lvalues are modifiable. An
array, like an object defined with the const qualifier, is an lvalue
but not a modifiable lvalue.

So prior to 1989, arrays were not lvalues. Since then they are, but
they are not modifiable lvalues. Unfortunately some compilers have
literally not updated the text of some of their diagnostic messages
since 1989.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq

[EPerson]

in*******@yahoo.com (ambika) wrote in message news:<bf**************************@posting.google. com>...

Hello,
Am not very good with pointers in C,but I have a small doubt about
the way these pointers work..
We all know that in an array say x[5],x is gonna point to the first
element in that array(i.e)it will have the address of the first
element.
No, x is refers to the whole array. It's just that in many cases it is
automatically converted into a pointer to the first element.
In the the program below am not able to increment the value
stored in x,which is the address of the first element.Why am I not
able to do that?Afterall 1 is also a hexadecimal number then why
does adding 1 to x show me a error?
You can't increment x, because you can't increment an array. Also,
hexadecimal has nothing to do with it. 0x1 is how you would write
hexadecimal 1 anyway.
I got the message "Lvalue Required" when I complied the program.Even
if I declared x[5] as long int the same error continued.Can
someone please help me solve it out??
Thanks to all those who are gonna help me in this..
--ambika

#include<stdio.h>
void main()
The return type of main shoud be int, not void.
{
int x[5]={1,2,3,4,5};
printf("\naddr in x:%p",x);
%p expects a generic pointer-to-void. So you should add a cast:

printf(addr in x:%p\n", (void *)x);

Note that I also moved the newline character to the end of the string,
which I believe is the intent.
printf("\nnumber in the addr stored in x is:%d",*x);
x=x+1;
This is not a valid assignment. The addition itself is in fact fine,
since x is converted to a pointer to x[0]. However, you then try to
assign the result (&x[1]) to an array. You can't assign to an array.
(Also, the error message "Lvalue Required" is incorrect, since x is an
lvalue. It's just not a modifiable lvalue.)
printf("\naddr in x after incrementation is:%p",x);
printf("\nnumber in the addr stored in x is:%d",*x);
Since the return type of main is now int, add a return statement here.
}

--
Eric Schmidt
#include <cool_sig.h>

[Michael Winter]

"Jack Klein" <ja*******@spamcop.net> wrote on 21 Sept 03:

On Sun, 21 Sep 2003 14:59:02 GMT, "Michael Winter"
<M.Winter@[no-spam]blueyonder.co.uk> wrote in comp.lang.c:

"ambika" wrote on 21 Sept 03:

Hello,
Am not very good with pointers in C,but I have a small doubt about
the way these pointers work..
We all know that in an array say x[5],x is gonna point to the first
element in that array(i.e)it will have the address of the first
element.In the the program below am not able to increment the value
stored in x,which is the address of the first element.Why am I not
able to do that?Afterall 1 is also a hexadecimal number then why
does adding 1 to x show me a error?
I got the message "Lvalue Required" when I complied the program.Even
if I declared x[5] as long int the same error continued.Can
someone please help me solve it out??
Thanks to all those who are gonna help me in this..
--ambika

#include<stdio.h>
void main()
{
int x[5]={1,2,3,4,5};
printf("\naddr in x:%p",x);
printf("\nnumber in the addr stored in x is:%d",*x);
x=x+1;
printf("\naddr in x after incrementation is:%p",x);
printf("\nnumber in the addr stored in x is:%d",*x);
}

x isn't really a pointer here, it's an identifier for an array. True, it does point to the first element, but you have to use it with subscripts.
There are two ways what you show above.

When will the nonsense stop? Not only is it true that "x isn't really
a pointer here", but it is also true that "x isn't really a pointer in
any way, shape, or form, not under any circumstances".

x does not point to the first element of anything, x is the name of an
array and is an object, not a pointer at all. It does not point to
anything at all.

OK, my choice of words were a bit off; they did imply that x was a pointer,
despite saying in the preceding sentence that it wasn't. I was probably
thinking at that time that with a low level implementation, x would identify
a memory location that held the base address of the array in a base-index
addressing scheme. My apologies.

1) Declare x as a pointer (int *) and allocate an array of integers to it. Now you could increment x, but it wouldn't be a good idea as you'd have to keep track of what changes you made, or store the original address
elsewhere, so you could get back to the original address for deallocation.
2) Use a separate pointer, like so:

int x[ 5 ] = { 1, 2, 3, 4, 5 };
int *p = x;

printf("\nfirst array element:%d", *p);
p++;
printf("\nsecond array element:%d\n", *p);

Mike

The rest of your suggestions are good, but your statements about x are
just plain wrong.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq

Mike

--
Michael Winter
M.Winter@[no-spam]blueyonder.co.uk (remove [no-spam] to reply)

[Gabriel Dos Reis]

Jack Klein <ja*******@spamcop.net> writes:

| > assert (*y == 3); // holds
| >
| > > I got the message "Lvalue Required" when I complied the program.Even
| > > if I declared x[5] as long int the same error continued.Can
| > > someone please help me solve it out??
| >
| > That's because arrays are not lvalues
|
| No, arrays are lvalues.

Not always.

-- Gaby

[thp]

In comp.std.c Jack Klein <ja*******@spamcop.net> wrote:
[...]
+ When will the nonsense stop? Not only is it true that "x isn't really
+ a pointer here", but it is also true that "x isn't really a pointer in
+ any way, shape, or form, not under any circumstances".
+
+ x does not point to the first element of anything, x is the name of an
+ array and is an object, not a pointer at all. It does not point to
+ anything at all.

Agreed. We must therefore distinguish between:

- the array object whose name is x.

- the value of the expression "x", which turns out to be a pointer
rvalue, namely the address of the first member of x.

Unfortunately, when we write "x" it isn't always clear which of these
we mean.

Tom Payne

[thp]

In comp.std.c th*@cs.ucr.edu wrote:
+ In comp.std.c Jack Klein <ja*******@spamcop.net> wrote:
+ [...]
+ + When will the nonsense stop? Not only is it true that "x isn't really
+ + a pointer here", but it is also true that "x isn't really a pointer in
+ + any way, shape, or form, not under any circumstances".
+ +
+ + x does not point to the first element of anything, x is the name of an
+ + array and is an object, not a pointer at all. It does not point to
+ + anything at all.
+
+ Agreed. We must therefore distinguish between:
+
+ - the array object whose name is x.
+
+ - the value of the expression "x", which turns out to be a pointer
+ rvalue, namely the address of the first member of x.

I should qualify this to most contexts. Certainly in the context of
an argument to sizeof "x" does designates the corresponding array
object.

+ Unfortunately, when we write "x" it isn't always clear which of these
+ we mean.
+
+ Tom Payne

[Irrwahn Grausewitz]

Gabriel Dos Reis <gd*@integrable-solutions.net> wrote:

Jack Klein <ja*******@spamcop.net> writes:

| > assert (*y == 3); // holds
| >
| > > I got the message "Lvalue Required" when I complied the program.Even
| > > if I declared x[5] as long int the same error continued.Can
| > > someone please help me solve it out??
| >
| > That's because arrays are not lvalues
|
| No, arrays are lvalues.

Not always.

For non-experts like me, in what contexts an array is not an lvalue?

Regards

Irrwahn
--
My other computer is a abacus.

[lawrence.jones]

In comp.std.c th*@cs.ucr.edu wrote:

- the value of the expression "x", which turns out to be a pointer
rvalue, namely the address of the first member of x.

That still isn't quite accurate -- the expression "x" is, in many cases,
automatically *converted* to a pointer, but it isn't itself a pointer.

-Larry Jones

I told her to expect you to deny everything. -- Calvin

[lawrence.jones]

In comp.std.c Irrwahn Grausewitz <ir*****************@freenet.de> wrote:

For non-experts like me, in what contexts an array is not an lvalue?

When it's a member of a struct (or union) that isn't a lvalue, like the
return value of a function.

-Larry Jones

I think if Santa is going to judge my behavior over the last year,
I ought to be entitled to legal representation. -- Calvin

[Micah Cowan]

la************@eds.com writes:

In comp.std.c Irrwahn Grausewitz <ir*****************@freenet.de> wrote:

For non-experts like me, in what contexts an array is not an lvalue?

When it's a member of a struct (or union) that isn't a lvalue, like the
return value of a function.

Huh. As I read the standard, this would result in you not being able
to use unary & on the array, but any use besides that or with sizeof
would result in a pointer to the first element of the array anyway.

Yes?

-Micah

[Irrwahn Grausewitz]

la************@eds.com wrote:

In comp.std.c Irrwahn Grausewitz <ir*****************@freenet.de> wrote:

For non-experts like me, in what contexts an array is not an lvalue?

When it's a member of a struct (or union) that isn't a lvalue, like the
return value of a function.

Ah, thanks for enlightment.

Irrwahn
--
My other computer is a abacus.

[lawrence.jones]

In comp.std.c Micah Cowan <mi***@cowan.name> wrote [about rvalue arrays]:

Huh. As I read the standard, this would result in you not being able
to use unary & on the array, but any use besides that or with sizeof
would result in a pointer to the first element of the array anyway.

Yes?

Yes. But that pointer has a very short lifetime (just until the next
sequence point).

-Larry Jones

Can I take an ax to school tomorrow for ... um ... show and tell? -- Calvin

[Victor]

Without worrying about what a modifiable lvalue is, it's probably
easiest to think of an array variable as a constant pointer.

Refer to the code below:

#include <stdlib.h>

int main( ) {

/* the compiler figures out how many array elements there are */
int x[ ] = { 8, 6, 7, 5, 3, 0, 9 };
/* allocate a block of 7 consecutive integers and assign this
address
* to the const pointer named xx
*/
int * const xx = ( int * ) malloc( 7 * sizeof( int ) );
const int *xp;
int i;

/* sizeof( ) will tell you how many bytes of storage, then divide
by the
size of each array element (an int typically is 4 bytes) to
determine
the number of array elements */
for ( i = 0; i < sizeof( x ) / sizeof( x[ 0 ] ); i++ )
/* perfectly legal, though it looks confusing... */
xx[ i ] = * ( x + i ) * -2;

/* assignment to a pointer to a constant int; contrast with this
xx, which
* is a constant pointer to an int.
*/
xp = x;
printf( "The 2nd element of array x is %d\n", * ( xp + 1 ) );
printf( "The 2nd element of array x is also this %d\n", xp[1] );
/* just showing off here a little bit... */
for ( i = 0; i < sizeof( x ) / sizeof( * ( x + 0 ) ); i++,xp++ )
printf( "x[ %d ] = %d\n", i, *xp );
/* note the different values returned by sizeof */
printf( "The size of x is %d, the size of xx is %d\n",
sizeof( x ), sizeof( xx ) );

for ( i = 0; i < sizeof( x ) / sizeof( int ); i++ )
printf( "element %d x: %d xx: %d\n", i, x[ i ], xx[ i ] );

/* I almost forgot this; you don't want to use dynamic memory
unless you
* truly have to, or like to give yourself fits with memory leaks.
*/
free ( xx );
return ( 0 );
}
The important things to note are that you can refer to array elements
as offsets from a pointer or using array brackets. Similarly, you can
also use the array brackets with a pointer. This suggests a close
correlation between pointers and array names. Note that you can store
the address of array, but you can not assign a value to an array name.
This is just like the constant pointer xx that I used above.

Using a pointer to a const int is a safe way to step through an array.
The compiler will warn you if you inadvertently attempt to modify
*xp. I hope this isn't more information than you wanted.

Best of luck,
Victor

in*******@yahoo.com (ambika) wrote in message news:<bf**************************@posting.google. com>...

Hello,
Am not very good with pointers in C,but I have a small doubt about
the way these pointers work..
We all know that in an array say x[5],x is gonna point to the first
element in that array(i.e)it will have the address of the first
element.In the the program below am not able to increment the value
stored in x,which is the address of the first element.Why am I not
able to do that?Afterall 1 is also a hexadecimal number then why
does adding 1 to x show me a error?
I got the message "Lvalue Required" when I complied the program.Even
if I declared x[5] as long int the same error continued.Can
someone please help me solve it out??
Thanks to all those who are gonna help me in this..
--ambika

#include<stdio.h>
void main()
{
int x[5]={1,2,3,4,5};
printf("\naddr in x:%p",x);
printf("\nnumber in the addr stored in x is:%d",*x);
x=x+1;
printf("\naddr in x after incrementation is:%p",x);
printf("\nnumber in the addr stored in x is:%d",*x);
}

[thp]

In comp.std.c la************@eds.com wrote:
+ In comp.std.c th*@cs.ucr.edu wrote:
+>
+> - the value of the expression "x", which turns out to be a pointer
+> rvalue, namely the address of the first member of x.
+
+ That still isn't quite accurate -- the expression "x" is, in many cases,
+ automatically *converted* to a pointer, but it isn't itself a pointer.

Perhaps, the referent of my use of "which" was ambiguous. In any
case, I mean that the *value* of the expression "x" turns out to be a
pointer rvalue (in all but a few cases).

Tom Payne

[Richard Heathfield]

Irrwahn Grausewitz wrote:

Gabriel Dos Reis <gd*@integrable-solutions.net> wrote:

Jack Klein <ja*******@spamcop.net> writes:
| No, arrays are lvalues.
Not always.

For non-experts like me, in what contexts an array is not an lvalue?

None. Jack is quite correct.

An array is not a /modifiable/ lvalue, but it /is/ an lvalue.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[Richard Heathfield]

Victor wrote:

Without worrying about what a modifiable lvalue is, it's probably
easiest to think of an array variable as a constant pointer.
int array[32];
const int *constptr = array;

printf("size of array is %lu bytes.\n", (unsigned long)sizeof array);
printf("size of pointer is %lu bytes.\n", (unsigned long)sizeof constptr);

<snip>
The important things to note are that you can refer to array elements
as offsets from a pointer or using array brackets. Similarly, you can
also use the array brackets with a pointer. This suggests a close
correlation between pointers and array names.

This is true, because the Standard guarantees that *(a + i) and a[i] are
synonymous.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[Irrwahn Grausewitz]

Richard Heathfield <do******@address.co.uk.invalid> wrote:

Irrwahn Grausewitz wrote:

Gabriel Dos Reis <gd*@integrable-solutions.net> wrote:

Jack Klein <ja*******@spamcop.net> writes:
| No, arrays are lvalues.
Not always.

For non-experts like me, in what contexts an array is not an lvalue?

None. Jack is quite correct.

An array is not a /modifiable/ lvalue, but it /is/ an lvalue.

Before confusion overwhelms me, let's see if I got it right:

1. In C99 arrays are lvalues, though not modifiable lvalues
(as stated in ISO/IEC 9899:1999 6.3.2.1#1).

2. There is no context that changes arrays from being (non-modifiable)
lvalues whatsoever.

3. Prior to C89 arrays weren't lvalues at all.

Right?

Regards

Irrwahn
--
My other computer is a abacus.

[Jack Klein]

On Tue, 23 Sep 2003 02:45:35 +0200, Irrwahn Grausewitz
<ir*****************@freenet.de> wrote in comp.lang.c:

Richard Heathfield <do******@address.co.uk.invalid> wrote:

Irrwahn Grausewitz wrote:

Gabriel Dos Reis <gd*@integrable-solutions.net> wrote:
Jack Klein <ja*******@spamcop.net> writes:
| No, arrays are lvalues.
Not always.
For non-experts like me, in what contexts an array is not an lvalue?

None. Jack is quite correct.

An array is not a /modifiable/ lvalue, but it /is/ an lvalue.

Before confusion overwhelms me, let's see if I got it right:

1. In C99 arrays are lvalues, though not modifiable lvalues
(as stated in ISO/IEC 9899:1999 6.3.2.1#1).

2. There is no context that changes arrays from being (non-modifiable)
lvalues whatsoever.

3. Prior to C89 arrays weren't lvalues at all.

Right?

Regards

Irrwahn

No, you are incorrect. It was the original 1989 ANSI standard that
made lvalues arrays and introduced the concept that some lvalues were
non-modifiable. That had to be so because the 1989 ANSI standard also
introduced the const qualifier to the language, and any object defined
as const was certainly an lvalue, but certainly not modifiable.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq

[Keith Thompson]

we******@yahoo.com (Victor) writes:

Without worrying about what a modifiable lvalue is, it's probably
easiest to think of an array variable as a constant pointer.

It's easiest (or at least most correct) to think of an array variable
as an array variable.

The name of an array variable, in most contexts, is *converted* to a
pointer to its first element.

--
Keith Thompson (The_Other_Keith) ks*@cts.com <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

[Gabriel Dos Reis]

Richard Heathfield <do******@address.co.uk.invalid> writes:

| Irrwahn Grausewitz wrote:
| > Gabriel Dos Reis <gd*@integrable-solutions.net> wrote:
| >>Jack Klein <ja*******@spamcop.net> writes:
| >>| No, arrays are lvalues.
| >>Not always.
| > For non-experts like me, in what contexts an array is not an lvalue?
|
| None.

Consider

struct Point {
int coord[2];
};

extern make_point(int, int);

The expression

make_point(34, 2).coord

is a non-lvalue array.

-- Gaby

[pete]

Gabriel Dos Reis wrote:

Richard Heathfield <do******@address.co.uk.invalid> writes:

| Irrwahn Grausewitz wrote:
| > Gabriel Dos Reis <gd*@integrable-solutions.net> wrote:
| >>Jack Klein <ja*******@spamcop.net> writes:
| >>| No, arrays are lvalues.
| >>Not always.
| > For non-experts like me, in what contexts an array is not an lvalue?
|
| None.

Consider

struct Point {
int coord[2];
};

extern make_point(int, int);

The expression

make_point(34, 2).coord

is a non-lvalue array.

Assuming that make_point returns the appropriate type structure,
what's nonlvalue about make_point(34, 2).coord ?
It designates an object, doesn't it.

--
pete

[Irrwahn Grausewitz]

Jack Klein <ja*******@spamcop.net> wrote:

On Tue, 23 Sep 2003 02:45:35 +0200, Irrwahn Grausewitz
<ir*****************@freenet.de> wrote in comp.lang.c:

1. In C99 arrays are lvalues, though not modifiable lvalues
(as stated in ISO/IEC 9899:1999 6.3.2.1#1).

2. There is no context that changes arrays from being (non-modifiable)
lvalues whatsoever.

3. Prior to C89 arrays weren't lvalues at all.

Right?

Regards

Irrwahn

No, you are incorrect. It was the original 1989 ANSI standard that
made lvalues arrays and introduced the concept that some lvalues were
non-modifiable. That had to be so because the 1989 ANSI standard also
introduced the const qualifier to the language, and any object defined
as const was certainly an lvalue, but certainly not modifiable.

And how does this contradict any of my above statements?!?
Ah, I see, for the sake of absolute correctness I should have written:

1. In C89 and C99 arrays are lvalues ...
=======

Irrwahn
--
My other computer is an abacus.

[Gabriel Dos Reis]

pete <pf*****@mindspring.com> writes:

| Gabriel Dos Reis wrote:
| >
| > Richard Heathfield <do******@address.co.uk.invalid> writes:
| >
| > | Irrwahn Grausewitz wrote:
| > | > Gabriel Dos Reis <gd*@integrable-solutions.net> wrote:
| > | >>Jack Klein <ja*******@spamcop.net> writes:
| > | >>| No, arrays are lvalues.
| > | >>Not always.
| > | > For non-experts like me, in what contexts an array is not an lvalue?
| > |
| > | None.
| >
| > Consider
| >
| > struct Point {
| > int coord[2];
| > };
| >
| > extern make_point(int, int);
^

oops, missing "struct Point"

| >
| > The expression
| >
| > make_point(34, 2).coord
| >
| > is a non-lvalue array.
|
| Assuming that make_point returns the appropriate type structure,
| what's nonlvalue about make_point(34, 2).coord ?

6.5.2.3

[#3] A postfix expression followed by the . operator and an
identifier designates a member of a structure or union
object. The value is that of the named member, and is an
lvalue if the first expression is an lvalue. If the first
expression has qualified type, the result has the so-
qualified version of the type of the designated member.

-- Gaby

[thp]

In comp.std.c pete <pf*****@mindspring.com> wrote:
+ Gabriel Dos Reis wrote:
+>
+> Richard Heathfield <do******@address.co.uk.invalid> writes:
+>
+> | Irrwahn Grausewitz wrote:
+> | > Gabriel Dos Reis <gd*@integrable-solutions.net> wrote:
+> | >>Jack Klein <ja*******@spamcop.net> writes:
+> | >>| No, arrays are lvalues.
+> | >>Not always.
+> | > For non-experts like me, in what contexts an array is not an lvalue?
+> |
+> | None.
+>
+> Consider
+>
+> struct Point {
+> int coord[2];
+> };
+>
+> extern make_point(int, int);
+>
+> The expression
+>
+> make_point(34, 2).coord
+>
+> is a non-lvalue array.
+
+ Assuming that make_point returns the appropriate type structure,
+ what's nonlvalue about make_point(34, 2).coord ?
+ It designates an object, doesn't it.

Since functions return structs by value, make_point(34,2) is not an
lvalue -- e.g., taking its address is a syntax error. So
make_point(34,2).coord is an array member of an rvalue, simply a
pointer rvalue pointing to make_point(34,2).coord[0]. However,
make_point(34,2).coord[0] is an lvalue.

Intricate stuff!

Tom Payne

[Sona]

Keith Thompson wrote:

we******@yahoo.com (Victor) writes:

Without worrying about what a modifiable lvalue is, it's probably
easiest to think of an array variable as a constant pointer.

It's easiest (or at least most correct) to think of an array variable
as an array variable.

The name of an array variable, in most contexts, is *converted* to a
pointer to its first element.

So in other words, if we're passing arrays to functions, we should
always do:

callSomeFunc(&someArray[0]);

Right? At least to make sure the code is portable? Thanks
Sona

[Chris Dollin]

Sona wrote:

Keith Thompson wrote:

we******@yahoo.com (Victor) writes:

Without worrying about what a modifiable lvalue is, it's probably
easiest to think of an array variable as a constant pointer.
It's easiest (or at least most correct) to think of an array variable
as an array variable.

The name of an array variable, in most contexts, is *converted* to a
pointer to its first element.

So in other words, if we're passing arrays to functions, we should
always do:

callSomeFunc(&someArray[0]);

Right?

No.
At least to make sure the code is portable? Thanks

No.

It's not necessary; arguments to functions are one of the places where
array names do decay into pointers to their first element.

[The two places where they don't are as operands to sizeof and monadic
&. The third place is for string literals used as initialisers for
string arrays.]

--
Chris "not Spanish, but sometimes Inquisitorial" Dollin
C FAQs at: http://www.faqs.org/faqs/by-newsgrou...mp.lang.c.html
C welcome: http://www.angelfire.com/ms3/bchambl...me_to_clc.html

[thp]

In comp.std.c Irrwahn Grausewitz <ir*****************@freenet.de> wrote:
[...]
+ Before confusion overwhelms me, let's see if I got it right:
[...]
+ 2. There is no context that changes arrays from being (non-modifiable)
+ lvalues whatsoever.

Arrays are arrays, and lvalues are expressions. Some but not all
array expressions are lvalues. Per C99 6.3.2.1:

Except when it is the operand of the sizeof operator or the
unary & operator, or is a string literal used to intialize
an array, an expression that has type "array of <type>" is
converted to an expression with type "pointer to <type>"
that points to the initial element of the array object and
is not an lvalue.

Also, Gabriel Dos Reis has posted an example of a non-lvalue array
expression that is not the result of such conversion.

Tom Payne

[Irrwahn Grausewitz]

Sona <so**********@nospam.com> wrote:

Keith Thompson wrote:

we******@yahoo.com (Victor) writes:

Without worrying about what a modifiable lvalue is, it's probably
easiest to think of an array variable as a constant pointer.

It's easiest (or at least most correct) to think of an array variable
as an array variable.

The name of an array variable, in most contexts, is *converted* to a
pointer to its first element.

So in other words, if we're passing arrays to functions, we should
always do:

callSomeFunc(&someArray[0]);

Which is indeed eqivalent to:

callSomeFunc( someArray );

To readers of c.lang.c and c.std.c this is aka Chris Torek's "The Rule":

<quote C.T.>

In any value context, an object of type 'array of T' is converted
to a value of type 'pointer to T', pointing to the first element
of that array, i.e., the one with subscript 0.

</quote C.T.>

Regards

Irrwahn
--
My other computer is an abacus.

[Keith Thompson]

Sona <so**********@nospam.com> writes:

Keith Thompson wrote:

we******@yahoo.com (Victor) writes:

Without worrying about what a modifiable lvalue is, it's probably
easiest to think of an array variable as a constant pointer.

It's easiest (or at least most correct) to think of an array variable
as an array variable.
The name of an array variable, in most contexts, is *converted* to a
pointer to its first element.

So in other words, if we're passing arrays to functions, we should
always do:

callSomeFunc(&someArray[0]);

Right? At least to make sure the code is portable? Thanks

No.

--
Keith Thompson (The_Other_Keith) ks*@cts.com <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

[Richard Heathfield]

[Much snippage]
Gabriel Dos Reis wrote:
IG: For non-experts like me, in what contexts an array is not an lvalue?
RJH: None.
GDR: Consider
GDR:
GDR: struct Point {
GDR: int coord[2];
GDR: };
GDR:
GDR: extern struct Point make_point(int, int);
GDR: 6.5.2.3

White flag. Thanks for pointing that out, and apologies to IG (et al) for
posting an incorrect answer to his question.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[Micah Cowan]

Irrwahn Grausewitz <ir*****************@freenet.de> writes:

Jack Klein <ja*******@spamcop.net> wrote:

On Tue, 23 Sep 2003 02:45:35 +0200, Irrwahn Grausewitz
<ir*****************@freenet.de> wrote in comp.lang.c:

1. In C99 arrays are lvalues, though not modifiable lvalues
(as stated in ISO/IEC 9899:1999 6.3.2.1#1).

2. There is no context that changes arrays from being (non-modifiable)
lvalues whatsoever.

3. Prior to C89 arrays weren't lvalues at all.

Right?

Regards

Irrwahn

No, you are incorrect. It was the original 1989 ANSI standard that
made lvalues arrays and introduced the concept that some lvalues were
non-modifiable. That had to be so because the 1989 ANSI standard also
introduced the const qualifier to the language, and any object defined
as const was certainly an lvalue, but certainly not modifiable.

And how does this contradict any of my above statements?!?
Ah, I see, for the sake of absolute correctness I should have written:

1. In C89 and C99 arrays are lvalues ...
=======

1. and 2. As has already been pointed out, arrays are not always
lvalues, in C89 nor in C99. The context provided was as a member of a
non-lvalue struct (e.g., returned from a function).

-Micah

[Micah Cowan]

th*@cs.ucr.edu writes:

In comp.std.c Irrwahn Grausewitz <ir*****************@freenet.de> wrote:
[...]
+ Before confusion overwhelms me, let's see if I got it right:
[...]
+ 2. There is no context that changes arrays from being (non-modifiable)
+ lvalues whatsoever.

Arrays are arrays, and lvalues are expressions. Some but not all
array expressions are lvalues. Per C99 6.3.2.1:

Except when it is the operand of the sizeof operator or the
unary & operator, or is a string literal used to intialize
an array, an expression that has type "array of <type>" is
converted to an expression with type "pointer to <type>"
that points to the initial element of the array object and
is not an lvalue.

Also, Gabriel Dos Reis has posted an example of a non-lvalue array
expression that is not the result of such conversion.

To others: note that the quote above has implications regarding
non-lvalue arrays when applied to an array-of-arrays type.

-Micah

[Bigdakine]

>Subject: doubt in USING POINTERS

From: in*******@yahoo.com (ambika)
Date: 9/21/03 4:28 AM Hawaiian Standard Time
Message-id: <bf**************************@posting.google.com >

Hello,
Am not very good with pointers in C,but I have a small doubt about
the way these pointers work..
We all know that in an array say x[5],x is gonna point to the first
element in that array(i.e)it will have the address of the first
element.In the the program below am not able to increment the value
stored in x,which is the address of the first element.Why am I not
able to do that?Afterall 1 is also a hexadecimal number then why
does adding 1 to x show me a error?
I got the message "Lvalue Required" when I complied the program.Even
if I declared x[5] as long int the same error continued.Can
someone please help me solve it out??
Thanks to all those who are gonna help me in this..
--ambika

#include<stdio.h>
void main()
{
int x[5]={1,2,3,4,5};
printf("\naddr in x:%p",x);
printf("\nnumber in the addr stored in x is:%d",*x);
x=x+1;
You can't increment x, which is a pointer to an array position like that,
hence you get the message unmodifiable L-value. Good thing too. All sorts of
trouble could result. Instead after defining x, add the statement
int ptr2xelem* = (int *) NULL;

And then set
ptr2xelem=&x[0];

And then you can write things like ptr2x++;
If you want to keep track of an index or something like that.
printf("\naddr in x after incrementation is:%p",x);
printf("\nnumber in the addr stored in x is:%d",*x);
}

Stuart

[Barry Schwarz]

On 23 Sep 2003 22:32:25 GMT, bi*******@aol.comGetaGrip (Bigdakine)
wrote:

Subject: doubt in USING POINTERS
From: in*******@yahoo.com (ambika)
Date: 9/21/03 4:28 AM Hawaiian Standard Time
Message-id: <bf**************************@posting.google.com >

Hello,
Am not very good with pointers in C,but I have a small doubt about
the way these pointers work..
We all know that in an array say x[5],x is gonna point to the first
element in that array(i.e)it will have the address of the first
element.In the the program below am not able to increment the value
stored in x,which is the address of the first element.Why am I not
able to do that?Afterall 1 is also a hexadecimal number then why
does adding 1 to x show me a error?
I got the message "Lvalue Required" when I complied the program.Even
if I declared x[5] as long int the same error continued.Can
someone please help me solve it out??
Thanks to all those who are gonna help me in this..
--ambika

#include<stdio.h>
void main()
{
int x[5]={1,2,3,4,5};
printf("\naddr in x:%p",x);
printf("\nnumber in the addr stored in x is:%d",*x);
x=x+1;
You can't increment x, which is a pointer to an array position like that,
hence you get the message unmodifiable L-value. Good thing too. All sorts of
trouble could result. Instead after defining x, add the statement
int ptr2xelem* = (int *) NULL;

If you are going to assign a real value to the pointer later, the
initialization is only window dressing . However, if you want to use
it, get rid of the ugly and useless cast. And while you are at it,
correct the syntax error.
int *ptr2xelem = NULL;
And then set
ptr2xelem=&x[0];
It would be just as correct to say
ptr2xelem = x;

And then you can write things like ptr2x++;
If you want to keep track of an index or something like that.

printf("\naddr in x after incrementation is:%p",x);
%p requires the corresponding argument be cast to void* and you
probably meant ptr2xelem, not x.
printf("\naddr in x after incrementation is:%p",(void*)ptr2xelem);
printf("\nnumber in the addr stored in x is:%d",*x);
ptr2xelem again.
}

<<Remove the del for email>>

[pete]

Gabriel Dos Reis wrote:

pete <pf*****@mindspring.com> writes:

| Gabriel Dos Reis wrote:
| >
| > Richard Heathfield <do******@address.co.uk.invalid> writes:
| >
| > | Irrwahn Grausewitz wrote:
| > | > Gabriel Dos Reis <gd*@integrable-solutions.net> wrote:
| > | >>Jack Klein <ja*******@spamcop.net> writes:
| > | >>| No, arrays are lvalues.
| > | >>Not always.
| > | > For non-experts like me, in what contexts an array is not an lvalue?
| > |
| > | None.
| >
| > Consider
| >
| > struct Point {
| > int coord[2];
| > };
| >
| > extern make_point(int, int);
^

oops, missing "struct Point"

| >
| > The expression
| >
| > make_point(34, 2).coord
| >
| > is a non-lvalue array.
|
| Assuming that make_point returns the appropriate type structure,
| what's nonlvalue about make_point(34, 2).coord ?

6.5.2.3

[#3] A postfix expression followed by the . operator and an
identifier designates a member of a structure or union
object. The value is that of the named member, and is an
lvalue if the first expression is an lvalue. If the first
expression has qualified type, the result has the so-
qualified version of the type of the designated member.

Thank you.
--
pete

[Mantorok Redgormor]

Gabriel Dos Reis <gd*@integrable-solutions.net> wrote in message news:<m3************@uniton.integrable-solutions.net>...

Richard Heathfield <do******@address.co.uk.invalid> writes:

| Irrwahn Grausewitz wrote:
| > Gabriel Dos Reis <gd*@integrable-solutions.net> wrote:
| >>Jack Klein <ja*******@spamcop.net> writes:
| >>| No, arrays are lvalues.
| >>Not always.
| > For non-experts like me, in what contexts an array is not an lvalue?
|
| None.

Consider

struct Point {
int coord[2];
};

extern make_point(int, int);

The expression

make_point(34, 2).coord
How are you allowed to use the '.' operator at the end of this function?
This is like saying:
strcpy(dest, src).coord

That makes no sense.. what am I missing here?

is a non-lvalue array.

-- Gaby

[Gabriel Dos Reis]

ne*****@tokyo.com (Mantorok Redgormor) writes:

| Gabriel Dos Reis <gd*@integrable-solutions.net> wrote in message news:<m3************@uniton.integrable-solutions.net>...
| > Richard Heathfield <do******@address.co.uk.invalid> writes:
| >
| > | Irrwahn Grausewitz wrote:
| > | > Gabriel Dos Reis <gd*@integrable-solutions.net> wrote:
| > | >>Jack Klein <ja*******@spamcop.net> writes:
| > | >>| No, arrays are lvalues.
| > | >>Not always.
| > | > For non-experts like me, in what contexts an array is not an lvalue?
| > |
| > | None.
| >
| > Consider
| >
| > struct Point {
| > int coord[2];
| > };
| >
| > extern make_point(int, int);
| >
| > The expression
| >
| > make_point(34, 2).coord
|
| How are you allowed to use the '.' operator at the end of this function?

The function make_point() is supposed to return "struct Point" -- as
corrected pointed by someone, and rectified in a subsequent message.

-- Gaby

[Mantorok Redgormor]

Gabriel Dos Reis <gd*@integrable-solutions.net> wrote in message news:<m3************@uniton.integrable-solutions.net>...

ne*****@tokyo.com (Mantorok Redgormor) writes:

| Gabriel Dos Reis <gd*@integrable-solutions.net> wrote in message news:<m3************@uniton.integrable-solutions.net>...
| > Richard Heathfield <do******@address.co.uk.invalid> writes:
| >
| > | Irrwahn Grausewitz wrote:
| > | > Gabriel Dos Reis <gd*@integrable-solutions.net> wrote:
| > | >>Jack Klein <ja*******@spamcop.net> writes:
| > | >>| No, arrays are lvalues.
| > | >>Not always.
| > | > For non-experts like me, in what contexts an array is not an lvalue?
| > |
| > | None.
| >
| > Consider
| >
| > struct Point {
| > int coord[2];
| > };
| >
| > extern make_point(int, int);
| >
| > The expression
| >
| > make_point(34, 2).coord
|
| How are you allowed to use the '.' operator at the end of this function?

The function make_point() is supposed to return "struct Point" -- as
corrected pointed by someone, and rectified in a subsequent message.

-- Gaby

Yes but why are you using the '.' member operator on a function?

Calling a function and trying to use the member operator '.' on it to
access a member of a struct is illegal.

- nethlek

[Mantorok Redgormor]

Gabriel Dos Reis <gd*@integrable-solutions.net> wrote in message news:<m3************@uniton.integrable-solutions.net>...

ne*****@tokyo.com (Mantorok Redgormor) writes:

| Gabriel Dos Reis <gd*@integrable-solutions.net> wrote in message news:<m3************@uniton.integrable-solutions.net>...
| > Richard Heathfield <do******@address.co.uk.invalid> writes:
| >
| > | Irrwahn Grausewitz wrote:
| > | > Gabriel Dos Reis <gd*@integrable-solutions.net> wrote:
| > | >>Jack Klein <ja*******@spamcop.net> writes:
| > | >>| No, arrays are lvalues.
| > | >>Not always.
| > | > For non-experts like me, in what contexts an array is not an lvalue?
| > |
| > | None.
| >
| > Consider
| >
| > struct Point {
| > int coord[2];
| > };
| >
| > extern make_point(int, int);
| >
| > The expression
| >
| > make_point(34, 2).coord
|
| How are you allowed to use the '.' operator at the end of this function?

The function make_point() is supposed to return "struct Point" -- as
corrected pointed by someone, and rectified in a subsequent message.

-- Gaby

Yes but why are you using the '.' member operator on a function?

Calling a function and trying to use the member operator '.' on it to
access a member of a struct is illegal.

- nethlek

[Irrwahn Grausewitz]

ne*****@tokyo.com (Mantorok Redgormor) wrote:

Gabriel Dos Reis <gd*@integrable-solutions.net> wrote in message news:<m3************@uniton.integrable-solutions.net>...

ne*****@tokyo.com (Mantorok Redgormor) writes:

| Gabriel Dos Reis <gd*@integrable-solutions.net> wrote in message news:<m3************@uniton.integrable-solutions.net>... <SNIP> | > struct Point {
| > int coord[2];
| > };
| >
| > extern make_point(int, int);
| >
| > The expression
| >
| > make_point(34, 2).coord
|
| How are you allowed to use the '.' operator at the end of this function?

The function make_point() is supposed to return "struct Point" -- as
corrected pointed by someone, and rectified in a subsequent message.

Yes but why are you using the '.' member operator on a function?

Calling a function and trying to use the member operator '.' on it to
access a member of a struct is illegal.

The '.' operator is applied to the _return value_ of the function, which
is a struct in this case.

Regards

Irrwahn
--
Great minds run in great circles.

[Irrwahn Grausewitz]

ne*****@tokyo.com (Mantorok Redgormor) wrote:

Gabriel Dos Reis <gd*@integrable-solutions.net> wrote in message news:<m3************@uniton.integrable-solutions.net>...

ne*****@tokyo.com (Mantorok Redgormor) writes:

| Gabriel Dos Reis <gd*@integrable-solutions.net> wrote in message news:<m3************@uniton.integrable-solutions.net>... <SNIP> | > struct Point {
| > int coord[2];
| > };
| >
| > extern make_point(int, int);
| >
| > The expression
| >
| > make_point(34, 2).coord
|
| How are you allowed to use the '.' operator at the end of this function?

The function make_point() is supposed to return "struct Point" -- as
corrected pointed by someone, and rectified in a subsequent message.

Yes but why are you using the '.' member operator on a function?

Calling a function and trying to use the member operator '.' on it to
access a member of a struct is illegal.

The '.' operator is applied to the _return value_ of the function, which
is a struct in this case.

Regards

Irrwahn
--
Great minds run in great circles.

[Gabriel Dos Reis]

ne*****@tokyo.com (Mantorok Redgormor) writes:
[...]

| > The function make_point() is supposed to return "struct Point" -- as
| > corrected pointed by someone, and rectified in a subsequent message.
| >
| > -- Gaby
|
| Yes but why are you using the '.' member operator on a function?

Because the expression make_point(34, 2) is a value of type struct Point.

| Calling a function and trying to use the member operator '.' on it to
| access a member of a struct is illegal.

No.

-- Gaby