Pointer to an array

[Sam]

I have a situation occuring in my code and I just can't see to figure
out why

I have an structure called employee that will put all of the employee
id's into a char array set to 10

struct Employee
{
char employeeid[100]; /* id of
employee*/
};
I build an array of 2 employee id's - that I am using for test purposes

employee id 1 = 8989890
employee id 2 = 9839399

both of this id's match the ids that are in the database

Just for clarification the employee array contains the correct values

I then store the pointer of this structure off into another structure
for later processing

this structure looks like this
static struct
{
long p1; <---------where I am going to store the pointer to the
employee array
} u_hstmt
The code looks like this after the employee array is built
u_hstmt.p1 = (long)&employee[0].employeeid; //save off the address of
the employee structure //
return();

FYI - I have tried (long)&employee[0] instead of
(long)&employee[0].employeeid and get the same results - I think that
(long)&employee[0] is the proper approach correct? because I want to
point to the address of the first occurence in the array Right?
I am storing off the array to a pointer because later on the u_hstmt
structure is the standard way we recall and use an array of selected
records.

This is the code that is executed
status = getemployeeinfo (&(((EMPID)u_hs tmt.p1)[count]));

EMPID equates to 10
count = 2
all said and done the called function uses
&(((EMPID)u_hst mt.p1)[u_hstmt[count] and equates it to a char * eid

All that being said

in the called function I do a display on eid and i see the 8989890(my
first valid eid from the original structure) and that goes on and does
it thing this tells me that I am on the right track

Then the second time the function is called i do a display on the eid
through the debugger tool and see that the value does not match

The second time I get 839399 as my second employee number when it
should be 9839399 - notice it is missing the first 9 in the employee id
- After some research I noticed that it is because it is off by one
character so if i were to go eid -1 then I would get 9839399 which is
the correct value for my second eid

the address value of the structure remains the same throughout only the
counter changes to get the next array of information.

Can someone tell me how my pointer to is getting the wrong information
for the second array if it is correct in the original structure and my
address that I am pointing too remains the intact? BTW I did not free
the original employee structure that I am pointing too.
Thanks

[Flash Gordon]

Sam wrote:

I have a situation occuring in my code and I just can't see to figure
out why

I have an structure called employee that will put all of the employee
id's into a char array set to 10

struct Employee
{
char employeeid[100]; /* id of
employee*/
The above looks more like 100 than 10 to me. Please copy and past actual
code, don't retype. It saves us having to guess what are typographical
errors and what are your real problems. Also, please don't use tabs when
posting to Usenet. Some people won't see any indentation at all because
some systems strip out tabs.
}; I build an array of 2 employee id's - that I am using for test purposes

employee id 1 = 8989890
employee id 2 = 9839399

both of this id's match the ids that are in the database

Just for clarification the employee array contains the correct values

I then store the pointer of this structure off into another structure
for later processing

this structure looks like this
static struct
{
long p1; <---------where I am going to store the pointer to the
employee array
long p1 is not a pointer and is not guaranteed to be able to hold a
pointer! If you want to store a pointer then store a pointer, not a
pointer converted to an integer!
} u_hstmt
The code looks like this after the employee array is built
u_hstmt.p1 = (long)&employee[0].employeeid; //save off the address of
the employee structure //
The cast is a sign that you are doing something stupid. See above
comment about storing the pointer.
return();
return is not a function, why the parenthesis? I'm not sure the empty
parenthesis is even legal!
FYI - I have tried (long)&employee[0] instead of
(long)&employee[0].employeeid and get the same results - I think that
(long)&employee[0] is the proper approach correct? because I want to
point to the address of the first occurence in the array Right?
Depends on what you are really trying to achieve. With the cast to long
it really makes no difference assuming employeeid is the first element
of the struct.

<snip>
Can someone tell me how my pointer to is getting the wrong information
for the second array if it is correct in the original structure and my
address that I am pointing too remains the intact? BTW I did not free
the original employee structure that I am pointing too.

You have an error on line 9388563957. If you don't have that many lines
in your C source file, then you need to extend it to that length then
fix the problem on that line.

In other words, if you don't post the actual code, a small complete
compilable program showing the problem, how can we tell you what you are
doing wrong? Although trying to store pointers as integers is almost
always the wrong thing to do and you have shown nothing that suggests
this is one of the few times when it might make sense.
--
Flash Gordon, living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidelines and intro:
http://clc-wiki.net/wiki/Intro_to_clc

[John Bode]

Sam wrote:

I have a situation occuring in my code and I just can't see to figure
out why

I have an structure called employee that will put all of the employee
id's into a char array set to 10

struct Employee
{
char employeeid[100]; /* id of
employee*/
};

Whoa. 10 or 100? Your post says one thing, but the code says
something else.

Or are you trying to store 10 10-character strings to a single array?
If so, you *really* don't want to do that.

I build an array of 2 employee id's - that I am using for test purposes

employee id 1 = 8989890
employee id 2 = 9839399

both of this id's match the ids that are in the database

Just for clarification the employee array contains the correct values

I then store the pointer of this structure off into another structure
for later processing

this structure looks like this
static struct
{
long p1; <---------where I am going to store the pointer to the
employee array
} u_hstmt
The code looks like this after the employee array is built
u_hstmt.p1 = (long)&employee[0].employeeid; //save off the address of
the employee structure //
Why are you storing a pointer value to a long datatype? Bad, bad, bad,
*BAD* juju. There's no guarantee that pointer types and integral types
have the same size or representation, and you can't rely on converting
a pointer value to a long and back again and have it still be
meaningful. Not to mention all the casting hoops you need to jump
through, which introduce yet more points of failure in your code. If
you need to store a pointer value, use a pointer datatype, like so:

static struct
{
struct Employee *p1;
} u_hstmt;
...
u_hstmt.p1 = employee; // see how using the right datatype
// makes things so much
simpler?

In most contexts, the type of the array identifier "decays" into a
pointer to the base type, and it's value is the address of the first
element of the array. So, given

struct Employee foo[10];
struct Employee *p;

the following statements are equivalent:

p = foo;
p = &foo[0];

In both cases, p is set to point to the first element of foo.
return();

FYI - I have tried (long)&employee[0] instead of
(long)&employee[0].employeeid and get the same results - I think that
(long)&employee[0] is the proper approach correct? because I want to
point to the address of the first occurence in the array Right?
You got the same results because the base address of the first member
of a struct instance and the base address of the struct instance itself
are the same, and you cast both results to the same datatype. Had you
used the proper pointer datatype for u_hstmt.p1, one of those would
have raised an error since the type of employee (struct Employee *) is
different from the type of employee[n].employeeid (char *).


I am storing off the array to a pointer because later on the u_hstmt
structure is the standard way we recall and use an array of selected
records.

This is the code that is executed
status = getemployeeinfo (&(((EMPID)u_hs tmt.p1)[count]));

EMPID equates to 10
count = 2
all said and done the called function uses
&(((EMPID)u_hst mt.p1)[u_hstmt[count] and equates it to a char * eid

You really need to cut and paste actual code, because the above lines
simply make no sense to me as written.
All that being said

in the called function I do a display on eid and i see the 8989890(my
first valid eid from the original structure) and that goes on and does
it thing this tells me that I am on the right track

Then the second time the function is called i do a display on the eid
through the debugger tool and see that the value does not match

The second time I get 839399 as my second employee number when it
should be 9839399 - notice it is missing the first 9 in the employee id
- After some research I noticed that it is because it is off by one
character so if i were to go eid -1 then I would get 9839399 which is
the correct value for my second eid

the address value of the structure remains the same throughout only the
counter changes to get the next array of information.

Can someone tell me how my pointer to is getting the wrong information
for the second array if it is correct in the original structure and my
address that I am pointing too remains the intact? BTW I did not free
the original employee structure that I am pointing too.

There isn't enough information in the code you've provided to know
where the problem is, although I suspect it stems from a fundamental
misunderstandin g of how pointers work. Start by making the changes I
suggested above, see what breaks, and that may lead you to the heart of
the problem. If you have more questions, feel free to ask, but
*please* cut and paste the actual code that's giving you problems.

Thanks

[C. Benson Manica]

Flash Gordon wrote:

return();

return is not a function, why the parenthesis? I'm not sure the empty
parenthesis is even legal!

Hm:

6.8.6.4 The return statement

1. A return statement with an expression shall not appear in a function
whose return type
is void. A return statement without an expression shall only appear in
a function
whose return type is void.

It seems that the legality of the empty parentheses depends on whether
the empty parens constitute an expression...

6.5.1 Primary expressions

5 A parenthesized expression is a primary expression. Its type and
value are identical to
those of the unparenthesized expression. It is an lvalue, a function
designator, or a void
expression if the unparenthesized expression is, respectively, an
lvalue, a function
designator, or a void expression.

If the parens don't enclose anything, it isn't a "parenthesi zed
expression", is it? Therefore is not return() legal in functions
declared to return void? In any case, I would argue that while it's
not great style, it's entirely possible OP is working with style
guidelines that require it (similar to those at my previous job, which
required parenthesized return statements except when the return type
was void).

[Keith Thompson]

"C. Benson Manica" <cb******@gmail .com> writes:

Flash Gordon wrote:

> return();

return is not a function, why the parenthesis? I'm not sure the empty
parenthesis is even legal!

Hm:

6.8.6.4 The return statement

1. A return statement with an expression shall not appear in a
function whose return type is void. A return statement without an
expression shall only appear in a function whose return type is
void.

It seems that the legality of the empty parentheses depends on whether
the empty parens constitute an expression...

6.5.1 Primary expressions

5 A parenthesized expression is a primary expression. Its type and
value are identical to those of the unparenthesized expression. It
is an lvalue, a function designator, or a void expression if the
unparenthesized expression is, respectively, an lvalue, a function
designator, or a void expression.

If the parens don't enclose anything, it isn't a "parenthesi zed
expression", is it? Therefore is not return() legal in functions
declared to return void? In any case, I would argue that while it's
not great style, it's entirely possible OP is working with style
guidelines that require it (similar to those at my previous job, which
required parenthesized return statements except when the return type
was void).

No, return() is a syntax error, regardless of the return type of the
function.

If the parens don't enclose anything then () is not a parenthesized
expression -- in fact, it's not an expression at all.

There are two forms of return statement:
return ;
and
return EXPRESSION ;

"return ();" doesn't match either of them.

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

[C. Benson Manica]

Keith Thompson wrote:

There are two forms of return statement:
return ;
and
return EXPRESSION ;
Is that text in n869 somewhere? I'm just curious, because given that,
"return ();" doesn't match either of them.

this clearly follows.

[Keith Thompson]

"C. Benson Manica" <cb******@gmail .com> writes:

Keith Thompson wrote:

There are two forms of return statement:
return ;
and
return EXPRESSION ;

Is that text in n869 somewhere? I'm just curious, because given that,

"return ();" doesn't match either of them.

this clearly follows.

Yes, section 6.8.6 defines the syntax of a jump-statement:

jump-statement:
goto identifier ;
continue ;
break ;
return expression(opt) ;

The "opt" is a subscript, indicating an optional expression.

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

[pete]

C. Benson Manica wrote:

If the parens don't enclose anything, it isn't a "parenthesi zed
expression", is it?

One thing that all expressions have in common
is that every expression has a type.

--
pete

[Christopher Benson-Manica]

Keith Thompson <ks***@mib.or g> wrote:

Yes, section 6.8.6 defines the syntax of a jump-statement: jump-statement:
goto identifier ;
continue ;
break ;
return expression(opt) ; The "opt" is a subscript, indicating an optional expression.

I saw that section but missed its import. Thanks.

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cybers pace.org | don't, I need to know. Flames welcome.