473,320 Members | 1,867 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

doubt in USING POINTERS

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);
}
Nov 13 '05
138 5072
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
Nov 13 '05 #51
ne*****@tokyo.com (Mantorok Redgormor) wrote in message news:<41**************************@posting.google. com>...
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.


The '.' is applied to the *value returned* by the function, which is
of a struct type. It's perfectly legal (and inspired a particularly
evil IOCCC entry, which had statements like a().b().c().e().f()...).
It's just not an lvalue.
Nov 13 '05 #52
ne*****@tokyo.com (Mantorok Redgormor) wrote in message news:<41**************************@posting.google. com>...
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.


The '.' is applied to the *value returned* by the function, which is
of a struct type. It's perfectly legal (and inspired a particularly
evil IOCCC entry, which had statements like a().b().c().e().f()...).
It's just not an lvalue.
Nov 13 '05 #53
Gabriel Dos Reis <gd*@integrable-solutions.net> wrote in message news:<m3************@uniton.integrable-solutions.net>...
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


I don't follow. The below is a program demonstrating my lack of
understanding. Could you change it to show what you are doing in a
practical example and how it works?

#include <stdio.h>

struct foo {
int coord[10];
};

static struct foo example(int );

int main(void)
{
/* The below is weird and demonstrates my lack of understanding */
example(10).coord;
/* What do we achieve in the above? how do we access coord?
* I am lost. Help my find my way to understanding */

return 0;
}

struct foo example(int a)
{
/* The below also demonstrates my lack of understanding of what is
* trying to be achieved here. */
static struct foo test;
return test;
}

This is really obfuscated use of a struct member so if you could point
out what the function example() is suppose to return and what is
suppose to happen with coord and how to access "coord" that would be
much appreciated.
Nov 13 '05 #54
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:

| 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.
I don't follow. The below is a program demonstrating my lack of
understanding. Could you change it to show what you are doing in a
practical example and how it works?

#include <stdio.h>

struct foo {
int coord[10];
};

static struct foo example(int );

int main(void)
{
/* The below is weird and demonstrates my lack of understanding */
example(10).coord;
/* What do we achieve in the above? how do we access coord?
* I am lost. Help my find my way to understanding */


1. The expression example(10) is evaluated, yielding a value
of type struct foo

2. The member coord of this value is accessed via the '.' operator

We access a member A of an object B of type struct C using the
struct member access operator. No magic.

return 0;
}

struct foo example(int a)
{
/* The below also demonstrates my lack of understanding of what is
* trying to be achieved here. */
static struct foo test;
return test;
}

This is really obfuscated use of a struct member so if you could point
out what the function example() is suppose to return and what is
suppose to happen with coord and how to access "coord" that would be
much appreciated.


It's as obfuscated as any other piece of C code. ;-)

example() is a function taking an argument of type int, returning
a value of struct foo.

test is an object of type struct foo with function scope (it is only
accessible in example()) and static storage duration (it gets
initialized on program startup and stays allocated till program
termination).

example() returns a copy of test when called.

Again, no magic.

Regards

Irrwahn
--
Great minds run in great circles.
Nov 13 '05 #55
On Thu, 25 Sep 2003, Irrwahn Grausewitz wrote:
struct foo {
int coord[10];
};
static struct foo example(int );


1. The expression example(10) is evaluated, yielding a value
of type struct foo

2. The member coord of this value is accessed via the '.' operator

We access a member A of an object B of type struct C using the
struct member access operator. No magic.


But if I write:

int *p=example(10).coord;

p is indeterminate here right? (since the instance of
struct foo isn't with us anymore)

Is example(10).coord[0] any different then?

Nov 13 '05 #56
Jarno A Wuolijoki <jw******@cs.Helsinki.FI> writes:

| But if I write:
|
| int *p=example(10).coord;
|
| p is indeterminate here right? (since the instance of
| struct foo isn't with us anymore)

p becomes a dangling pointer, yes.

| Is example(10).coord[0] any different then?

Yes.

int x = example(10).coord[0];

is well defined;
Nov 13 '05 #57
In article <m3************@uniton.integrable-solutions.net>,
Gabriel Dos Reis <gd*@integrable-solutions.net> wrote:
Jarno A Wuolijoki <jw******@cs.Helsinki.FI> writes:

| But if I write:
|
| int *p=example(10).coord;
|
| p is indeterminate here right? (since the instance of
| struct foo isn't with us anymore)

p becomes a dangling pointer, yes.

| Is example(10).coord[0] any different then?

Yes.

int x = example(10).coord[0];

is well defined;


Maybe the following will help.

x = example(10).a;

is for the most part equivalent to:

{ struct foo temp;
temp = example(10);
x = a;
}

The main difference I can think of offhand is that you can use
example(10).a in an expression, but you can't use the equivalent sequence
of statements involving the temp variable so concisely.

--
Barry Margolin, ba************@level3.com
Level(3), Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Nov 13 '05 #58
On Thu, 25 Sep 2003, Barry Margolin wrote:
| Is example(10).coord[0] any different then?

Yes.
int x = example(10).coord[0];
is well defined;


Maybe the following will help.

x = example(10).a;
is for the most part equivalent to:

{ struct foo temp;
temp = example(10);
x = a;
}


But is

x=example(10).coord[0];

equivalent to

{ int *temp;
{ struct foo temp2;
temp2 = example(10);
temp = temp2.coord;
}
x=temp[0];
}

or

{ int *temp;
struct foo temp2;
temp2 = example(10);
temp = temp2.coord;
x=temp[0];
}

?

Nov 13 '05 #59
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

is a non-lvalue array.

-- Gaby


After playing around with this and getting a better understanding I
see how it all works. But, is this array really an array or does coord
just decay into a pointer to the arrays first element? And if so, in
that case the array is not really an rvalue just a pointer to the
array is.

Which is equivalent in saying the array in the following example is an
rvalue:

int arr[10];
int *p;

p = arr; /*
* arr just decays into a pointer to int -- so the array is
not really
* an rvalue but a pointer to int instead, which designates
the
* appropriate object.
*/
Nov 13 '05 #60
ne*****@tokyo.com (Mantorok Redgormor) writes:

| After playing around with this and getting a better understanding I
| see how it all works. But, is this array really an array or does coord
| just decay into a pointer to the arrays first element?

It is an array, albeit a non-lvalue. It can decay to pointer in
appropriate context (e.g. function call argument). You can even take
its sizeof and compute its length.

-- Gaby
Nov 13 '05 #61
In article <Pi*************************************@melkinpaa si.cs.Helsinki.FI>,
Jarno A Wuolijoki <jw******@cs.Helsinki.FI> wrote:
But is

x=example(10).coord[0];

equivalent to

{ int *temp;
{ struct foo temp2;
temp2 = example(10);
temp = temp2.coord;
}
x=temp[0];
}

or

{ int *temp;
struct foo temp2;
temp2 = example(10);
temp = temp2.coord;
x=temp[0];
}

?


The latter. In the first one, temp is a pointer to an object whose
lifetime has ended when the inner block finishes.

If any temporaries are needed to evaluate an expression, their lifetimes
all must include the entire expression. In some cases it may be possible
to determine that some are no longer needed earlier in the processing, so
an optimizer can eliminate them. But in this case the structure has to
live until the array is dereferenced.

--
Barry Margolin, ba************@level3.com
Level(3), Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Nov 13 '05 #62
Gabriel Dos Reis <gd*@integrable-solutions.net> wrote in message news:<m3************@uniton.integrable-solutions.net>...
ne*****@tokyo.com (Mantorok Redgormor) writes:

| After playing around with this and getting a better understanding I
| see how it all works. But, is this array really an array or does coord
| just decay into a pointer to the arrays first element?

It is an array, albeit a non-lvalue. It can decay to pointer in
appropriate context (e.g. function call argument). You can even take
its sizeof and compute its length.

-- Gaby


This is great. I have never known this. In this specific context an
array on the right-hand side of an assignment operator does not decay
into a pointer to its first element!

I put together the following example:

#include <stdio.h>
struct foo { int array[10]; };
static struct foo example(int);
int main(void)
{
printf("%u\n", sizeof example(10).array);

return 0;
}

struct foo example(int a)
{
static struct foo woo;
woo.array[0] = a; /* pointless */
return woo;
}
But now, something I found to be bizarre was the fact that sizeof
computed the size of the array. I only say this is bizzare because I
thought sizeof did not evaluate its operand? In this specific case it
would have to evaluate its operand to get the size, right?
Furthermore, it would have to compute this size at run-time and not
compile-time, correct?
Nov 13 '05 #63
j

"Mantorok Redgormor" <ne*****@tokyo.com> wrote in message
news:41**************************@posting.google.c om...
Gabriel Dos Reis <gd*@integrable-solutions.net> wrote in message

news:<m3************@uniton.integrable-solutions.net>...
ne*****@tokyo.com (Mantorok Redgormor) writes:

| After playing around with this and getting a better understanding I
| see how it all works. But, is this array really an array or does coord
| just decay into a pointer to the arrays first element?

It is an array, albeit a non-lvalue. It can decay to pointer in
appropriate context (e.g. function call argument). You can even take
its sizeof and compute its length.

-- Gaby


This is great. I have never known this. In this specific context an
array on the right-hand side of an assignment operator does not decay
into a pointer to its first element!

I put together the following example:

#include <stdio.h>
struct foo { int array[10]; };
static struct foo example(int);
int main(void)
{
printf("%u\n", sizeof example(10).array);

return 0;
}

struct foo example(int a)
{
static struct foo woo;
woo.array[0] = a; /* pointless */
return woo;
}
But now, something I found to be bizarre was the fact that sizeof
computed the size of the array. I only say this is bizzare because I
thought sizeof did not evaluate its operand? In this specific case it
would have to evaluate its operand to get the size, right?
Furthermore, it would have to compute this size at run-time and not
compile-time, correct?


With a later version of gcc(2.96-113 redhat) I get a diagnostic when
attempting to assign to a pointer to int.
int *p;
p = example(10).array;
``invalid use of non-lvalue array''

With gcc 3.2.1 I get ``incompatible types in assignment''

and with lcc-win32 it compiles fine.

Either this is a bug in gcc, or lcc is in violation of the standard.

Is the array member of the struct actually decaying into a pointer to its
first element(int *) or is it actually not decaying?
Nov 13 '05 #64
ne*****@tokyo.com (Mantorok Redgormor) wrote in message news:<41**************************@posting.google. com>...
....
I put together the following example:

#include <stdio.h>
struct foo { int array[10]; };
static struct foo example(int);
int main(void)
{
printf("%u\n", sizeof example(10).array);

return 0;
}

struct foo example(int a)
{
static struct foo woo;
woo.array[0] = a; /* pointless */
return woo;
}
But now, something I found to be bizarre was the fact that sizeof
computed the size of the array. I only say this is bizzare because I
thought sizeof did not evaluate its operand? In this specific case it
would have to evaluate its operand to get the size, right?
The term "evaluate" means "determine the value of"; the value of
example(10).array is not needed here. All that's needed for "sizeof
example(10).array" is the return type of example(), which is struct
foo, and the type of 'array' (int[10]). An actual call to example() is
not needed, nor are the values stored in array needed.
Furthermore, it would have to compute this size at run-time and not
compile-time, correct?


No, since it does not depend in any way upon the actual value returned
by example().
Nov 13 '05 #65
The "sizeof" is an operator. The argument to the sizeof operator is
always available to compiler at compile time. And the specification
says that the for array type variables, the sizeof should return the
total number of bytes that array can hold.
The behaviour can be verified for any type of the array.
The array can be a part of the structure declaration but this
information is also available at compile time hence if you are using
sizeof anywhere in the program as here the value calculated by sizeof
will be replaced by 40 (assuming int is 4 bytes i.e. 4*10=40).

You can also verify it by compiling the code with an compiler option
that generates assembly listing. You will find the value calculated by
sizeof operator in the assembly listing generated.
DG
__________________________________________________ _____________________________
ne*****@tokyo.com (Mantorok Redgormor) wrote in message news:<41**************************@posting.google. com>...
Gabriel Dos Reis <gd*@integrable-solutions.net> wrote in message news:<m3************@uniton.integrable-solutions.net>...
ne*****@tokyo.com (Mantorok Redgormor) writes:

| After playing around with this and getting a better understanding I
| see how it all works. But, is this array really an array or does coord
| just decay into a pointer to the arrays first element?

It is an array, albeit a non-lvalue. It can decay to pointer in
appropriate context (e.g. function call argument). You can even take
its sizeof and compute its length.

-- Gaby


This is great. I have never known this. In this specific context an
array on the right-hand side of an assignment operator does not decay
into a pointer to its first element!

I put together the following example:

#include <stdio.h>
struct foo { int array[10]; };
static struct foo example(int);
int main(void)
{
printf("%u\n", sizeof example(10).array);

return 0;
}

struct foo example(int a)
{
static struct foo woo;
woo.array[0] = a; /* pointless */
return woo;
}
But now, something I found to be bizarre was the fact that sizeof
computed the size of the array. I only say this is bizzare because I
thought sizeof did not evaluate its operand? In this specific case it
would have to evaluate its operand to get the size, right?
Furthermore, it would have to compute this size at run-time and not
compile-time, correct?

Nov 13 '05 #66
On 27 Sep 2003 04:34:02 -0700, dg*****@hss.hns.com (Deepak) wrote:
The "sizeof" is an operator. The argument to the sizeof operator is
always available to compiler at compile time. And the specification


Except in the case of variable length arrays allowed in C99.
<<Remove the del for email>>
Nov 13 '05 #67
ne*****@tokyo.com (Mantorok Redgormor) writes:

| But now, something I found to be bizarre was the fact that sizeof
| computed the size of the array. I only say this is bizzare because I
| thought sizeof did not evaluate its operand?

It does not evaluate its operand, except when it does. In the
specific example you showed, it does not evaluate its operand; what it
does it compute its type, which is know at translation type.

-- Gaby
Nov 13 '05 #68
j

"Gabriel Dos Reis" <gd*@integrable-solutions.net> wrote in message
news:m3************@uniton.integrable-solutions.net...
Jarno A Wuolijoki <jw******@cs.Helsinki.FI> writes:

| But if I write:
|
| int *p=example(10).coord;
|
| p is indeterminate here right? (since the instance of
| struct foo isn't with us anymore)

p becomes a dangling pointer, yes.
Initializing or assigning p the address of coord doesn't seem to be the case
on gcc(that is, it doesn't work). This however works with lcc. Is this a bug
with gcc or is lcc in violation of the standard? Shouldn't coord decay into
a pointer to the first element of the array?

| Is example(10).coord[0] any different then?

Yes.

int x = example(10).coord[0];

is well defined;

Nov 13 '05 #69
In comp.std.c j <ja*******@bellsouth.net> wrote:
| int *p=example(10).coord;


Initializing or assigning p the address of coord doesn't seem to be the case
on gcc(that is, it doesn't work). This however works with lcc. Is this a bug
with gcc or is lcc in violation of the standard? Shouldn't coord decay into
a pointer to the first element of the array?


In C99, yes; in C90, no. (In C90, the array to pointer conversion only
happened for lvalue arrays.)

-Larry Jones

Apparently I was misinformed. -- Calvin
Nov 13 '05 #70
la************@eds.com wrote:
In comp.std.c j <ja*******@bellsouth.net> wrote:
| int *p=example(10).coord;


Initializing or assigning p the address of coord doesn't seem to
be the case on gcc (that is, it doesn't work). This however works
with lcc. Is this a bug with gcc or is lcc in violation of the
standard? Shouldn't coord decay into a pointer to the first
element of the array?


In C99, yes; in C90, no. (In C90, the array to pointer conversion
only happened for lvalue arrays.)


Assuming the field coord is defined as an int array, what is wrong
with:

int *p = &(example(10).coord);

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Nov 13 '05 #71
j

"CBFalconer" <cb********@yahoo.com> wrote in message
news:3F***************@yahoo.com...
la************@eds.com wrote:
In comp.std.c j <ja*******@bellsouth.net> wrote:

> | int *p=example(10).coord;

Initializing or assigning p the address of coord doesn't seem to
be the case on gcc (that is, it doesn't work). This however works
with lcc. Is this a bug with gcc or is lcc in violation of the
standard? Shouldn't coord decay into a pointer to the first
element of the array?
In C99, yes; in C90, no. (In C90, the array to pointer conversion
only happened for lvalue arrays.)


Assuming the field coord is defined as an int array, what is wrong
with:

int *p = &(example(10).coord);


Well, & operates on an lvalue. And since coord is considered to be a
non-lvalue -- in this context -- in c90, then you can't use the address-of
operator on it.

Would anyone mind quoting the relevant section in c90 for this by the way?
Or is there some free draft for c90 that I could take a look at? I would
just like to compare the differences between c90 and c99.


--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

Nov 13 '05 #72
j wrote:
"CBFalconer" <cb********@yahoo.com> wrote in message
la************@eds.com wrote:
In comp.std.c j <ja*******@bellsouth.net> wrote:
>
>> | int *p=example(10).coord;
>
> Initializing or assigning p the address of coord doesn't seem to
> be the case on gcc (that is, it doesn't work). This however works
> with lcc. Is this a bug with gcc or is lcc in violation of the
> standard? Shouldn't coord decay into a pointer to the first
> element of the array?

In C99, yes; in C90, no. (In C90, the array to pointer conversion
only happened for lvalue arrays.)


Assuming the field coord is defined as an int array, what is wrong
with:

int *p = &(example(10).coord);


Well, & operates on an lvalue. And since coord is considered to be a
non-lvalue -- in this context -- in c90, then you can't use the
address-of operator on it.


On reflection, true. There is no guarantee that the return value
from example() has any sort of address, in fact the reverse is
probably true. On this reasoning C99 should not allow this
either.

So we would have to write:

int *p;
thing t; /* where thing is a suitable struct */
...
t = example(10);
p = &(t.coord);

The basic problem is that earlier someone snipped the definitions
of example() and what it returns. I knew I should have put in
some such :-(

To answer the original question, lcc is faulty if it allows this.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Nov 13 '05 #73
"j" <ja*******@bellsouth.net> writes:

| "Gabriel Dos Reis" <gd*@integrable-solutions.net> wrote in message
| news:m3************@uniton.integrable-solutions.net...
| > Jarno A Wuolijoki <jw******@cs.Helsinki.FI> writes:
| >
| > | But if I write:
| > |
| > | int *p=example(10).coord;
| > |
| > | p is indeterminate here right? (since the instance of
| > | struct foo isn't with us anymore)
| >
| > p becomes a dangling pointer, yes.
|
| Initializing or assigning p the address of coord doesn't seem to be the case
| on gcc(that is, it doesn't work).

If with -std=c99, you still see the same behaviour, then that is a bug
in the GCC/gcc compiler.

-- Gaby
Nov 13 '05 #74
Gabriel Dos Reis <gd*@integrable-solutions.net> writes:
[...]
If with -std=c99, you still see the same behaviour, then that is a bug
in the GCC/gcc compiler.


I got an internal compiler error in gcc with the following program:

struct foo {
int arr[10];
};

static struct foo func(void)
{
struct foo result;
return result;
}

int main(void)
{
int *ptr = func().arr;
return 0;
}

I've reported it to the gcc bugzilla system; see
<http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12446>.

(I'm not quite sure what gcc *should* do with this.)

--
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"
Nov 13 '05 #75
Keith Thompson <ks*@cts.com> writes:

| Gabriel Dos Reis <gd*@integrable-solutions.net> writes:
| [...]
| > If with -std=c99, you still see the same behaviour, then that is a bug
| > in the GCC/gcc compiler.
|
| I got an internal compiler error in gcc with the following program:

Odd.
Anyway, an ICE is (almost) always a bug in the compiler.

[...]

| int main(void)
| {
| int *ptr = func().arr;
| return 0;
| }
|
| I've reported it to the gcc bugzilla system; see
| <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12446>.

Thanks!

| (I'm not quite sure what gcc *should* do with this.)

decay func().arr to a pointer, successfully complete the translation,
and generate a sensible executable.

-- Gaby
Nov 13 '05 #76
In comp.std.c j <ja*******@bellsouth.net> wrote:

Would anyone mind quoting the relevant section in c90 for this by the way?
Or is there some free draft for c90 that I could take a look at? I would
just like to compare the differences between c90 and c99.


Except when it is the operand of the sizeof operator or the
unary & operator, or is a character string literal used to
initialize an array of character type, or is a wide string
literal used to initialize an array with element type compatible
with wchar_t, an lvalue that has type ``array of type'' is
converted to an expression that has type ``pointer to type''
that points to the initial element of the array object and is
not an lvalue.

The key difference between C90 and C99 is that "an lvalue that has type"
changed to "an expression that has type". There were also changes to
the "&" operator, but I don't think they're relevant in this context.

-Larry Jones

Ha! Wild zontars couldn't drag that information out of me! Do your worst!
-- Calvin
Nov 13 '05 #77
In comp.std.c j <ja*******@bellsouth.net> wrote:

Well, & operates on an lvalue. And since coord is considered to be a
non-lvalue -- in this context -- in c90, then you can't use the address-of
operator on it.


Interestingly enough, the same is true in C99. Although the implicit
conversion works, the & operator still requires an lvalue.

-Larry Jones

From now on, I'm devoting myself to the cultivation of
interpersonal relationships. -- Calvin
Nov 13 '05 #78
In comp.std.c CBFalconer <cb********@yahoo.com> wrote:

On reflection, true. There is no guarantee that the return value
from example() has any sort of address, in fact the reverse is
probably true. On this reasoning C99 should not allow this
either.


The theory is that the return value has to be stored somewhere and thus
has a conceptual address, even if it's not in the usual address space,
and the resulting pointer has such a short lifetime that the compiler
can get the right answer without too much work, even if it has to be
special-cased.

-Larry Jones

Years from now when I'm successful and happy, ...and he's in
prison... I hope I'm not too mature to gloat. -- Calvin
Nov 13 '05 #79
>Keith Thompson <ks*@cts.com> writes:
I got an internal compiler error in gcc with the following program:
int main(void)
{
int *ptr = func().arr;
return 0;
}
In article <m3************@uniton.integrable-solutions.net>
Gabriel Dos Reis <gd*@integrable-solutions.net> writes:
... an ICE is (almost) always a bug in the compiler.


You do not need the "(almost)" part, unless the machine on which
the compiler is being run is not working correctly (in which case
it becomes difficult to trust anything at all :-) ).
(I'm not quite sure what gcc *should* do with this.)


decay func().arr to a pointer, successfully complete the translation,
and generate a sensible executable.


The problem here is that there is no really sensible answer.

According to others who should know, the expression "func().arr"
is *not* an lvalue in C89/C90, but *is* an lvalue in C99.

Since it is not an operand of the unary "&" or sizeof operators,
the array lvalue will become a pointer rvalue, so in C99 the
assignment appears to be legal but useless, and a warning would be
appropriate.

In C89/C90, however, this is the one unique case in which an array
is an "rvalue", and the whole thing appears to be an error with a
required diagnostic, or perhaps an error with no required diagnostic.
But writing:
int (*p)[N] = &(func().arr);
would definitely require a diagnostic, because unary & can only
be applied to lvalues.

The way I prefer to describe situations involving arrays uses
somewhat different terminology from that in the C standards. In
my notation, we have "objects" and "values", rather than "lvalues"
and "values". In other words, we eliminate the whole concept of
"lvalue" as basically flawed and confusing. (This escapes the
weirdness surrounding "modifiable" vs "non-modifiable" lvalues, in
particular.) But even here we have a problem. The value returned
by a function is definitely a "value", not an "object", yet in this
case the value is a structure.

Normally structures can only exist in "complete object" form. For
instance:

struct S a, b;
...
a = b;

Here "a" and "b" both name entire objects. While "b" is in a "value
context", so that b's value is copied to a, it is obvious "where
this value lives" -- in the object named by b -- and its lifetime
is equally obvious. If b contains an array member named "arr",
writing:

int *ptr = b.arr;

causes b to point to the first element of the array by the usual
application of what I call "The Rule" about arrays and pointers in
C. The lifetime of that array is the lifetime of b; its place in
storage is determined by b's place; and so on.

Function return values, however, have no defined storage location.
Normally this never even comes up: If functions could return
arrays, we would have to resolve the question of what it means to
write:

int g(void)[N];
int *x = g();

and the answer to that would clearly be the same as the answer to
what it means to write:

int *p = func().arr;

but since functions cannot return arrays -- the declaration of g()
above must draw a diagnostic -- the first situation never occurs.
Only in this one case, when a function returns a structure that
contains at least one array as a member, do we have to find an
answer.

Ultimately, I think there are two reasonable answers: forbid this
entirely -- make a claim that an array value, in this one case in
which it occurs, has no address and cannot be used in any way
(including to subscript it) -- or state that the value of an "array
value" is the value of the address of the first element of that
array, just as with an array object, so that the assignment to p
is valid and well-defined, and so that subscripting works in the
usual way. If the second answer is chosen (as I think it is in
C99), we must then define the lifetime of the object to which this
pointer points. I think that lifetime should be "until the next
sequence point", so that the assignment to p, while valid, is
useless and probably deserves a warning.

The folks defining C seem to have chosen both answers (at different
times in different standards). :-)
--
In-Real-Life: Chris Torek, Wind River Systems (BSD engineering)
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://67.40.109.61/torek/index.html (for the moment)
Reading email is like searching for food in the garbage, thanks to spammers.
Nov 13 '05 #80
Gabriel Dos Reis <gd*@integrable-solutions.net> writes:
Keith Thompson <ks*@cts.com> writes:

| Gabriel Dos Reis <gd*@integrable-solutions.net> writes:
| [...]
| > If with -std=c99, you still see the same behaviour, then that is a bug
| > in the GCC/gcc compiler.
|
| I got an internal compiler error in gcc with the following program:

Odd.
Anyway, an ICE is (almost) always a bug in the compiler.

[...]

| int main(void)
| {
| int *ptr = func().arr;
| return 0;
| }
|
| I've reported it to the gcc bugzilla system; see
| <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12446>.

Thanks!

| (I'm not quite sure what gcc *should* do with this.)

decay func().arr to a pointer, successfully complete the translation,
and generate a sensible executable.


Which appears to be what it does if you specify "-std=c99"; at least
it doesn't cause an ICE. (When I submitted the bug report, I had
thought for some reason that I had seen the same behavior with and
without "-std=c99"; fortunately my description was correct anyway.)

I still wonder about the semantics of this. I've just tried another
test program that assigns a value to *ptr and then prints it out.
This doesn't, of course, imply that doing so is valid; it could still
be undefined behavior.

The question is, what is the lifetime of the int object that ptr
points to? It's part of the value returned by a function, so I
normally wouldn't expect it to outlive the expression containing the
call, but being able to grab a pointer to it makes it all very
confusing.

--
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"
Nov 13 '05 #81
thp
In comp.std.c Chris Torek <no****@elf.eng.bsdi.com> wrote:
[...]
+ The way I prefer to describe situations involving arrays uses
+ somewhat different terminology from that in the C standards. In
+ my notation, we have "objects" and "values", rather than "lvalues"
+ and "values".

Agreed. C89/90 attempted to define an "lvalue" to be an object-valued
expression but ran afoul of the fact that to maintain sanity we must
accept "*0" as an lvalue. We might slip out of that embarrassment by
positing a "null object" that *0 designates, but what's its type?
Obviously, the matter gets even more difficult when there are
reference types.

Things remain sane if we accept that there are objects and there are
values, and that some expressions (called rvalues) will always
designate a value, while others (called lvalues) will not represent
values but will not necessarily designate objects eithers.
Unfortunately, the distinction doesn't rest on type, since per the C
Standard, both "3" and "int x" are of the same type, namely int.

Tom Payne
Nov 13 '05 #82
la************@eds.com wrote:
In comp.std.c CBFalconer <cb********@yahoo.com> wrote:

On reflection, true. There is no guarantee that the return value
from example() has any sort of address, in fact the reverse is
probably true. On this reasoning C99 should not allow this
either.


The theory is that the return value has to be stored somewhere and
thus has a conceptual address, even if it's not in the usual address
space, and the resulting pointer has such a short lifetime that the
compiler can get the right answer without too much work, even if it
has to be special-cased.


Since C, unlike Pascal, allows a return value to be ignored, such
needs to be (in practice) easily done. The easiest method is
returning it in a register, and failing to store that register.
Registers do not have an address in the usual memory space. Thus
I see no reason for allowing taking the address of a returned
value, or a component thereof.

If C99 allows this I consider it an unnecessary burden on code
generators.

(read in c.l.c)

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Nov 13 '05 #83
Keith Thompson <ks*@cts.com> writes:

[...]

| I still wonder about the semantics of this. I've just tried another
| test program that assigns a value to *ptr and then prints it out.
| This doesn't, of course, imply that doing so is valid; it could still
| be undefined behavior.

If it does something like

print_value(set_value(func().arr, 4));

I would expect it to be valid -- I do not know any Standard text that
implies so, though.
In C++, which as the same notion of non-lvalue array, that would be
valid.

| The question is, what is the lifetime of the int object that ptr
| points to?

What I've found quite intriguing in the Standard is I'm under the
impression that the notion of lifetime of temporaries has been
completely hand waved.

| It's part of the value returned by a function, so I
| normally wouldn't expect it to outlive the expression containing the
| call, but being able to grab a pointer to it makes it all very
| confusing.

Yup.

In C++, the issue has been resolved by stating that the lifetime of a
temporary lasts until the end of the full expression it is part of.

-- Gaby
Nov 13 '05 #84
Chris Torek <no****@elf.eng.bsdi.com> writes:

| >> (I'm not quite sure what gcc *should* do with this.)
| >
| >decay func().arr to a pointer, successfully complete the translation,
| >and generate a sensible executable.
|
| The problem here is that there is no really sensible answer.
|
| According to others who should know, the expression "func().arr"
| is *not* an lvalue in C89/C90, but *is* an lvalue in C99.

It has been repeatedly shown that func().arr is not an lvalue in C99.
Which chapter and verse of the standard make you believe it is an
lvalue in C99?

-- Gaby
Nov 13 '05 #85
th*@cs.ucr.edu wrote:
In comp.std.c Chris Torek <no****@elf.eng.bsdi.com> wrote:
[...]
+ The way I prefer to describe situations involving arrays uses
+ somewhat different terminology from that in the C standards. In
+ my notation, we have "objects" and "values", rather than "lvalues"
+ and "values".

Agreed. C89/90 attempted to define an "lvalue" to be an object-valued
expression but ran afoul of the fact that to maintain sanity we must
accept "*0" as an lvalue.


I don't see why. "*0" violates a constraint.

Jeremy.
Nov 13 '05 #86
CBFalconer wrote:

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

....
The theory is that the return value has to be stored somewhere and
thus has a conceptual address, even if it's not in the usual address
space, and the resulting pointer has such a short lifetime that the
compiler can get the right answer without too much work, even if it
has to be special-cased.


Since C, unlike Pascal, allows a return value to be ignored, such
needs to be (in practice) easily done. The easiest method is
returning it in a register, and failing to store that register.
Registers do not have an address in the usual memory space. Thus
I see no reason for allowing taking the address of a returned
value, or a component thereof.

If C99 allows this I consider it an unnecessary burden on code
generators.


As I understand the argument, it only applies to the case where the
address being taken is the address of a member of structure. It's only
rarely possible to squeeze a structure into a register; I don't think
it's a major burden on code generators to effectively prohibit that
option.
Nov 13 '05 #87
Keith Thompson wrote:
....
I still wonder about the semantics of this. I've just tried another
test program that assigns a value to *ptr and then prints it out.
This doesn't, of course, imply that doing so is valid; it could still
be undefined behavior.

The question is, what is the lifetime of the int object that ptr
points to? It's part of the value returned by a function, so I
normally wouldn't expect it to outlive the expression containing the
call, but being able to grab a pointer to it makes it all very
confusing.


You're correct. The lifetime of that int object is the same as the
lifetime of the structure object it's a member of: the full-expression
containing the function call. It outlasts the function call itself, and
can therefore be used in parts of the same full-expression that are
guaranteed to be evaluated after the function call, but it cannot be
used in the next statement after the one containing the function call.
Nov 13 '05 #88
James Kuyper <ku****@saicmodis.com> writes:

| Keith Thompson wrote:
| ...
| > I still wonder about the semantics of this. I've just tried another
| > test program that assigns a value to *ptr and then prints it out.
| > This doesn't, of course, imply that doing so is valid; it could still
| > be undefined behavior.
| >
| > The question is, what is the lifetime of the int object that ptr
| > points to? It's part of the value returned by a function, so I
| > normally wouldn't expect it to outlive the expression containing the
| > call, but being able to grab a pointer to it makes it all very
| > confusing.
|
| You're correct. The lifetime of that int object is the same as the
| lifetime of the structure object it's a member of: the full-expression
| containing the function call. It outlasts the function call itself, and
| can therefore be used in parts of the same full-expression that are
| guaranteed to be evaluated after the function call, but it cannot be
| used in the next statement after the one containing the function call.

Do you have formal reference(s) for that claim?

-- Gaby
Nov 13 '05 #89
thp
In comp.std.c Jeremy Yallop <je****@jdyallop.freeserve.co.uk> wrote:
+ th*@cs.ucr.edu wrote:
+> In comp.std.c Chris Torek <no****@elf.eng.bsdi.com> wrote:
+> [...]
+> + The way I prefer to describe situations involving arrays uses
+> + somewhat different terminology from that in the C standards. In
+> + my notation, we have "objects" and "values", rather than "lvalues"
+> + and "values".
+>
+> Agreed. C89/90 attempted to define an "lvalue" to be an object-valued
+> expression but ran afoul of the fact that to maintain sanity we must
+> accept "*0" as an lvalue.
+
+ I don't see why. "*0" violates a constraint.

The expression "*0" doesn't denote an object.

Tom Payne
Nov 13 '05 #90
In message <3F***************@saicmodis.com>
James Kuyper <ku****@saicmodis.com> wrote:
CBFalconer wrote:
Since C, unlike Pascal, allows a return value to be ignored, such
needs to be (in practice) easily done. The easiest method is
returning it in a register, and failing to store that register.
Registers do not have an address in the usual memory space. Thus
I see no reason for allowing taking the address of a returned
value, or a component thereof.

If C99 allows this I consider it an unnecessary burden on code
generators.


As I understand the argument, it only applies to the case where the
address being taken is the address of a member of structure. It's only
rarely possible to squeeze a structure into a register; I don't think
it's a major burden on code generators to effectively prohibit that
option.


For what it's worth, the ARM calling standard mandates that some word-sized
structures/unions are returned in an integer register. Changing the calling
convention would be an even worse burden than getting the compiler to cope
with taking the address of a register-returned value.

And why are we only worried about structure returns here? Doesn't C99's new
lvalue definition also allow weird things like

int *x = &abs(1);
*&abs(3) = 2

I suppose the difference is that such cases cannot be required to actually
do anything useful?

--
Kevin Bracey, Principal Software Engineer
Tematic Ltd Tel: +44 (0) 1223 503464
182-190 Newmarket Road Fax: +44 (0) 1223 503458
Cambridge, CB5 8HE, United Kingdom WWW: http://www.tematic.com/
Nov 13 '05 #91
Gabriel Dos Reis <gd*@integrable-solutions.net> wrote in
news:m3************@uniton.integrable-solutions.net:
Keith Thompson <ks*@cts.com> writes:

[...]

| I still wonder about the semantics of this. I've just tried another
| test program that assigns a value to *ptr and then prints it out.
| This doesn't, of course, imply that doing so is valid; it could still
| be undefined behavior.

If it does something like

print_value(set_value(func().arr, 4));

I would expect it to be valid -- I do not know any Standard text that
implies so, though.


It's not valid in C99, assuming set_value() does the
obvious. C99 6.5.2.2p5 says (in part):

If an attempt is made to modify the result of a function
call or to access it after the next sequence point, the
behavior is undefined.

So set_value cannot modify the result of func(). What is
more, C99 6.5.2.2p10 says:

The order of evaluation of the function designator, the
actual arguments, and subexpressions within the actual
arguments is unspecified, but there is a sequence point
before the actual call.

So there is a sequence point after func() returns but before
the call to set_value(), and therefore set_value() is not
even allowed to access the result of func().

--
Phil T
Nov 13 '05 #92
CBFalconer wrote:
I see no reason for allowing taking the address of a returned
value, or a component thereof.


Actually I agree with you, but this seems a minor matter.
In one case the compiler does a little extra work and in
the other case the programmer does a little extra work.
Nov 13 '05 #93
Phil Tregoning <Ph**************@esa.notthisbit.int> writes:

| Gabriel Dos Reis <gd*@integrable-solutions.net> wrote in
| news:m3************@uniton.integrable-solutions.net:
|
| > Keith Thompson <ks*@cts.com> writes:
| >
| > [...]
| >
| >| I still wonder about the semantics of this. I've just tried another
| >| test program that assigns a value to *ptr and then prints it out.
| >| This doesn't, of course, imply that doing so is valid; it could still
| >| be undefined behavior.
| >
| > If it does something like
| >
| > print_value(set_value(func().arr, 4));
| >
| > I would expect it to be valid -- I do not know any Standard text that
| > implies so, though.
|
| It's not valid in C99, assuming set_value() does the
| obvious. C99 6.5.2.2p5 says (in part):
|
| If an attempt is made to modify the result of a function
| call or to access it after the next sequence point, the
| behavior is undefined.
|
| So set_value cannot modify the result of func(). What is
| more, C99 6.5.2.2p10 says:
|
| The order of evaluation of the function designator, the
| actual arguments, and subexpressions within the actual
| arguments is unspecified, but there is a sequence point
| before the actual call.
|
| So there is a sequence point after func() returns but before
| the call to set_value(), and therefore set_value() is not
| even allowed to access the result of func().

Thanks for the remind.

By the same token, print_value(func().arr) is undefined behaviour.

Well, the notion is of limited usefulness.

Yet, another incompatibility with C++.

-- Gaby
Nov 13 '05 #94
Chris Torek wrote:
Function return values, however, have no defined storage location.


Actually, results of expressions generally don't have defined
storage locations (i.e. correspond to what the C standard calls
"objects"). Whether or not they must is essentially what
lvalueness is about, and the decision is made on an operator-
by-operator basis judging on the basis of how useful it would
be to the programmer versus the potential cost in the generated
code.
Nov 13 '05 #95
"Douglas A. Gwyn" <DA****@null.net> writes:

| CBFalconer wrote:
| > I see no reason for allowing taking the address of a returned
| > value, or a component thereof.
|
| Actually I agree with you, but this seems a minor matter.
| In one case the compiler does a little extra work and in
| the other case the programmer does a little extra work.

And I would refer having the compiler do the little extra work.

-- Gaby
Nov 13 '05 #96
th*@cs.ucr.edu wrote:
Agreed. C89/90 attempted to define an "lvalue" to be an object-valued
expression but ran afoul of the fact that to maintain sanity we must
accept "*0" as an lvalue. We might slip out of that embarrassment by
positing a "null object" that *0 designates, but what's its type?
Obviously, the matter gets even more difficult when there are
reference types.


That's completely wacky. "*0" is not allowed in strictly conforming
programs, does not occur in any program I know of, and is perforce
irrelevant to the C standard.
Nov 13 '05 #97
In comp.std.c Chris Torek <no****@elf.eng.bsdi.com> wrote:

According to others who should know, the expression "func().arr"
is *not* an lvalue in C89/C90, but *is* an lvalue in C99.
No, it's not an lvalue in C99, either. It's just that "The Rule"
applies only to lvalues in C89 but applies to any expression in C99.
Since it is not an operand of the unary "&" or sizeof operators,
the array lvalue will become a pointer rvalue, so in C99 the
assignment appears to be legal but useless, and a warning would be
appropriate.
Exactly.
In C89/C90, however, this is the one unique case in which an array
is an "rvalue", and the whole thing appears to be an error with a
required diagnostic, or perhaps an error with no required diagnostic.
It's a constraint violation (on the assignment operator), so a
diagnostic is required.
But writing:
int (*p)[N] = &(func().arr);
would definitely require a diagnostic, because unary & can only
be applied to lvalues.
True in both C89/C90 and C99.
Ultimately, I think there are two reasonable answers: forbid this
entirely -- make a claim that an array value, in this one case in
which it occurs, has no address and cannot be used in any way
(including to subscript it) -- or state that the value of an "array
value" is the value of the address of the first element of that
array, just as with an array object, so that the assignment to p
is valid and well-defined, and so that subscripting works in the
usual way. If the second answer is chosen (as I think it is in
C99), we must then define the lifetime of the object to which this
pointer points. I think that lifetime should be "until the next
sequence point", so that the assignment to p, while valid, is
useless and probably deserves a warning.

The folks defining C seem to have chosen both answers (at different
times in different standards). :-)


Correct. The former was the decision made for C89, the latter
(including the lifetime of the object) was the decision made for C99.

-Larry Jones

My upbringing is filled with inconsistent messages. -- Calvin
Nov 13 '05 #98
In comp.std.c Keith Thompson <ks*@cts.com> wrote:

The question is, what is the lifetime of the int object that ptr
points to?


Until the next sequence point.

-Larry Jones

I thought my life would seem more interesting with a musical
score and a laugh track. -- Calvin
Nov 13 '05 #99
In comp.std.c Gabriel Dos Reis <gd*@integrable-solutions.net> wrote:

Keith Thompson <ks*@cts.com> writes:
|
| (I'm not quite sure what gcc *should* do with this.)

decay func().arr to a pointer, successfully complete the translation,
and generate a sensible executable.


And a warning that the pointer you stored is useless.

-Larry Jones

Rats. I can't tell my gum from my Silly Putty. -- Calvin
Nov 13 '05 #100

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

22
by: srivatsan_b | last post by:
Hi, Can somebody explain whether an explicit typecast is mandatory while calling memset function for a structure? like in the following code snapshot..... struct some_structure x;...
28
by: dutche | last post by:
Hi, there is some kind of difference in these two statements? float num = 154.87; printf("There is : $0.0f",num); and float num = 154.87;
10
by: Pedro Pinto | last post by:
Hi there! I'm creating a function that copies some information to a buffer and enters a delimiter string "//" between results. My issue here is when i print the buffer it appears this weird...
6
by: reji_thomas | last post by:
Hi, I have a doubt in the following code: struct xyz { int x; long l; float f; };
5
by: subramanian | last post by:
Consdier the following program: #include <stdio.h> struct typeRecord { int id; char str; } records = { {0, "zero"}, {1, "one"},
4
by: Deep | last post by:
I'm in doubt about what is smart pointer. so, please give me simple description about smart pointer and an example of that. I'm just novice in c++. regards, John.
26
by: Vashna | last post by:
Hi Group, I have a doubt about register variables. I know that if we have a variable used very frequently in a function, then provided we never apply the & function to it, we can define it as...
1
by: sridhard2406 | last post by:
Hi All, I have a doubt on undrestanding Dangling pointers.Below I mentioned sample code. please let me know, my view on Dangling pointers is correct or not? main( ) ...
5
by: nembo kid | last post by:
In the following function, s shouldn't be a pointer costant (array's name)? So why it is legal its increment? Thanks in advance. /* Code starts here */ void chartobyte (char *s) { while...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
0
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
0
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.