size of pointer variables

J

junky_fellow

Can the size of pointer variables of different type may be
different on a particular architecture.
For eg.

Can the sizeof (char *) be different from sizeof(int *) or
sizeof (void *) ?

What is the purpose of using a void pointer ? Instead of
declaring a pointer variable "void *", can I declare it
as "char *" and then later on typcast it to whatever type
as needed.

Thanx for any any help in advance ...
 
B

bjrnove

Hi.

In theory the size of a char* and a int* can be different. I never seen
it myself, and I don't think it's very common. The purpose of the void*
is to prevent this problem. You can always be shure that a void* will
fit into anything, and can take the value of any pointer.
 
I

Ivan Vecerina

Can the size of pointer variables of different type may be
different on a particular architecture.
For eg.

Can the sizeof (char *) be different from sizeof(int *) or
sizeof (void *) ?
Click to expand...
char* and int* can be different, although I have never used
such a system.
For example:
A platform could have 32 or 64-bit words as the smallest
addressable unit, yet choose to support 8-bit char-s by
storing an extra 'byte offset' along with the address.

I can't think of char* and void* having different sizes,
but I do not remember if/how the ISO standard specifically
mandates that they must have the same size.
What is the purpose of using a void pointer ? Instead of
declaring a pointer variable "void *", can I declare it
as "char *" and then later on typcast it to whatever type
as needed.
Click to expand...
Sometimes the use of char* is required anyway to be able to
perform some pointer arithmetic (in platform-specific code).
Actually, 'unsigned char*' is to be preferred, as it
additionally can be used to copy raw memory.

This said, void* better expresses the fact that the pointer
refers to the address of an object that may have any type.
Thanx for any any help in advance ...
Click to expand...

hth-Ivan
 
R

Richard Bos

Ivan Vecerina said:
char* and int* can be different, although I have never used
such a system.
Click to expand...
I can't think of char* and void* having different sizes,
but I do not remember if/how the ISO standard specifically
mandates that they must have the same size.
Click to expand...

Yes. The same representation, as well.

Using void *, you don't need the cast, which is cleaner.

Richard
 
J

jacob navia

Pointers to different regions of memory can be different.
In a small 16 bit DSP with only 4K RAM, RAM pointers can be 16
bit, but large EPROM pointers (512K or more) can be 24 bits.

In this C implementation, large pointers are differentiated from small
ones by using special keywords.

This has nothing to do with the type of the data stored in those
memory regions of course, unless only a special kind of data
is stored in a region.

To take a more well known example in the DOS operating system
there are "near" pointers (16 bit) and "far" pointers (32 bits).

With the new 64 bits systems in PCs there can be "near" pointers
(32 bit) and "far" pointers with the full 64 bits address range.

jakob
 
L

Lawrence Kirby

Hi.

In theory the size of a char* and a int* can be different. I never seen
it myself, and I don't think it's very common. The purpose of the void*
is to prevent this problem. You can always be shure that a void* will
fit into anything, and can take the value of any pointer.
Click to expand...

That is also true of pointer to character types. void * pointers are
required to have the same representation as pointers to character types.
You can convert, say, an int * pointer to void * or a pointer to a
character type and back again, and you will get the original pointer value
back although the intermediate representation may be different. With void
* you don't need to cast. Without void * functions like memcpy() would
have argument types like char *, which means that many calls to memcpy()
would need casts on the arguments which is messy.

Lawrence
 
L

Lawrence Kirby

Pointers to different regions of memory can be different.
Click to expand...

But not in standard C. In standard C all pointers to a particular type on
an implementation have the same size.
In a small 16 bit DSP with only 4K RAM, RAM pointers can be 16
bit, but large EPROM pointers (512K or more) can be 24 bits.

In this C implementation, large pointers are differentiated from small
ones by using special keywords.
Click to expand...

Possibly true but irrelevant to the question, which is about whether
pointers with different standard C types can have different sizes. And the
answer to that is yes, other than for some specific cases (e.g. void * and
all pointer to character types are required to use the same representation).
This has nothing to do with the type of the data stored in those memory
regions of course, unless only a special kind of data is stored in a
region.

To take a more well known example in the DOS operating system there are
"near" pointers (16 bit) and "far" pointers (32 bits).
Click to expand...

And consider that the original question was topical for comp.lang.c but
your answer is well off topic and possibly confusing becuase it has
nothing to do with standard C.

Lawrence
 
R

Richard Bos

[ Have Wanadoo gone the Way of the Dev^h^h^hGoogle, too? Quote some
context, man! ]
Pointers to different regions of memory can be different.
In a small 16 bit DSP with only 4K RAM, RAM pointers can be 16
bit, but large EPROM pointers (512K or more) can be 24 bits.

In this C implementation, large pointers are differentiated from small
ones by using special keywords.
Click to expand...

"This" C implementation? Which "this" C implementation do you take for
so normative that you don't need to name it - MSVC++###?
This has nothing to do with the type of the data stored in those
memory regions of course, unless only a special kind of data
is stored in a region.

To take a more well known example in the DOS operating system
there are "near" pointers (16 bit) and "far" pointers (32 bits).
Click to expand...

You talk as if this is the main way in which pointers may differ, and as
if different kinds of pointers will always (or usually) be distinguished
by such extra keywords. They will not.

Richard
 
M

Malcolm

Can the size of pointer variables of different type may be
different on a particular architecture.
For eg.

Can the sizeof (char *) be different from sizeof(int *) or
sizeof (void *) ?
Click to expand...
Let's say we've got a machine that only adresses memory in 32-bit chunks
(bytes).
One obvious strategy would be to say that chars are 32 bits. This has some
problems. For instance an image-processing routine that takes an array of
unsigned chars as its argument would now gobble four times as much memory as
necessary, or need to be rewritten.
So the alternative is to make chars 8 bit, and do a bit of bit twiddling
behind the scenes to produce the illusion of 8-bit bytes.
But if our addresses are multiples of 32 bits, we need to tag on an extra
two bits to tell us where the pointer points to.
So char pointers become
{
address:
offset:
}

The whole reason the machine accesses data in 32 bit bytes is for
efficiency, so we don't want to encumber our int *s and double *s with
similar tags. That would slow everything down.

so char pointers and int pointers are now a different size.
What is the purpose of using a void pointer ? Instead of
declaring a pointer variable "void *", can I declare it
as "char *" and then later on typcast it to whatever type
as needed.
Click to expand...
That was the old-fashioned way of doing things. void * is more for
documentation, to tell the programmer that "this pointer points to memory of
unknown type".
unsigned char * can point to any memory. In practise
double x;
(unsigned char *ptr) = &x;
double *dblptr = (double *) ptr;

will work on pretty much any platform. However it might just be the case
that the double pointers need to carry around an extra bit for some reason,
in which case the code will break. void pointers, of course, are guaranteed
to be able to hold any type.
 
J

junky_fellow

Malcolm said:
Let's say we've got a machine that only adresses memory in 32-bit chunks
(bytes).
One obvious strategy would be to say that chars are 32 bits. This has some
problems. For instance an image-processing routine that takes an array of
unsigned chars as its argument would now gobble four times as much memory as
necessary, or need to be rewritten.
So the alternative is to make chars 8 bit, and do a bit of bit twiddling
behind the scenes to produce the illusion of 8-bit bytes.
But if our addresses are multiples of 32 bits, we need to tag on an extra
two bits to tell us where the pointer points to.
So char pointers become
{
address:
offset:
}

The whole reason the machine accesses data in 32 bit bytes is for
efficiency, so we don't want to encumber our int *s and double *s with
similar tags. That would slow everything down.

so char pointers and int pointers are now a different size.
That was the old-fashioned way of doing things. void * is more for
documentation, to tell the programmer that "this pointer points to memory of
unknown type".
unsigned char * can point to any memory. In practise
double x;
(unsigned char *ptr) = &x;
double *dblptr = (double *) ptr;

will work on pretty much any platform. However it might just be the case
that the double pointers need to carry around an extra bit for some reason,
in which case the code will break. void pointers, of course, are guaranteed
to be able to hold any type.
Click to expand...

Thank you to everyone for your help.
What I concluded is that since the size/representation of pointer
variables to
different data types may be different even on the same platform, we
should not
typecast one type pointer to other type except void pointer.

In some of the code pieces, I have seen that there is some pointer to a

structure. To initialize the structure with zero, the structure
pointer is typecasted to (char *) and passed as an argument to bzero().
Is this the right thing to do ?
I will give you the example.
typedef struct node {
long l;
int i ;
short s1;
short s2;
char c;
}node_t;

node_t * pstr_node;
bzero(((char *)pstr_node, sizeof (*pstr_node));

Is this legal ? Can we typecast structure pointer to char pointer ?



Let it be,
 
B

bjrnove

typedef struct node {
long l;
int i ;
short s1;
short s2;
char c;


}node_t;


node_t * pstr_node;
bzero(((char *)pstr_node, sizeof (*pstr_node));


Is this legal ? Can we typecast structure pointer to char pointer ?
Click to expand...

Yes, it is. I would prefere sizeof(node_t), but it really doesn't
matter. I do not know what bzero does (not standard c), but I presume
the call above would be the same as memset(pstr_node, 0x00,
sizeof(node_t)). In your code above though, it will crash since your
pointer points to garbage. I would recomend you to use unsigned char
when you make your own functions like bzero, because char could be both
signed and unsigned (that's up to your compiler).
 
J

Jason Curl

Malcolm said:
Let's say we've got a machine that only adresses memory in 32-bit chunks
(bytes).
One obvious strategy would be to say that chars are 32 bits. This has some
problems. For instance an image-processing routine that takes an array of
unsigned chars as its argument would now gobble four times as much memory as
necessary, or need to be rewritten.
So the alternative is to make chars 8 bit, and do a bit of bit twiddling
behind the scenes to produce the illusion of 8-bit bytes.
But if our addresses are multiples of 32 bits, we need to tag on an extra
two bits to tell us where the pointer points to.
So char pointers become
{
address:
offset:
}

The whole reason the machine accesses data in 32 bit bytes is for
efficiency, so we don't want to encumber our int *s and double *s with
similar tags. That would slow everything down.

so char pointers and int pointers are now a different size.


That was the old-fashioned way of doing things. void * is more for
documentation, to tell the programmer that "this pointer points to memory of
unknown type".
unsigned char * can point to any memory. In practise
double x;
(unsigned char *ptr) = &x;
double *dblptr = (double *) ptr;

will work on pretty much any platform. However it might just be the case
that the double pointers need to carry around an extra bit for some reason,
in which case the code will break. void pointers, of course, are guaranteed
to be able to hold any type.
Click to expand...

I have a question - I believed that the representation of char* and
void* are the same representation? If I'm right, then I don't see how
the last paragraph suits.
 
R

Richard Bos

typedef struct node {
long l;
int i ;
short s1;
short s2;
char c;
}node_t;

node_t * pstr_node;
bzero(((char *)pstr_node, sizeof (*pstr_node));

Is this legal ? Can we typecast structure pointer to char pointer ?
Click to expand...

The code is not legal, for a couple of reasons. First, bzero() is not an
ISO C function. Second, you don't initialise pstr_node, so it points
nowhere when you pass it to bzero(). Third, you have a parenthesis too
many (and two superfluous, but harmless ones. BTW, I disagree with
bjrnove on using sizeof (node_t); the way you have it is more solid.).

The cast in itself, though, is legal; everything can be cast to a char
*, which must have the same size and representation as a void *, so like
a void *, it can represent all other kinds of pointers.
It is probably superfluous, though, since the most usual implementations
of bzero() take a void * as their first argument, and you can pass any
object pointer as a parameter declared as void *, without a cast.

Richard
 
J

junky_fellow

Richard said:
The code is not legal, for a couple of reasons. First, bzero() is not an
ISO C function. Second, you don't initialise pstr_node, so it points
nowhere when you pass it to bzero(). Third, you have a parenthesis too
many (and two superfluous, but harmless ones. BTW, I disagree with
bjrnove on using sizeof (node_t); the way you have it is more solid.).
Click to expand...
Can you please specify why sizeof(*pstr_node) is better as compared
to sizeof(struct node_t) ? I thought they both are equivalent.
The cast in itself, though, is legal; everything can be cast to a char
*, which must have the same size and representation as a void *, so like
a void *, it can represent all other kinds of pointers.
It is probably superfluous, though, since the most usual implementations
of bzero() take a void * as their first argument, and you can pass any
object pointer as a parameter declared as void *, without a cast.

Richard
Click to expand...

That means pointer variable to any type may be typecasted to (char *)
but *not* the viceversa ?
 
R

Richard Bos

Can you please specify why sizeof(*pstr_node) is better as compared
to sizeof(struct node_t) ? I thought they both are equivalent.
Click to expand...

To the compiler, yes, they're equivalent. But consider what happens if
you change pstr_node from a node_t to a newnode_t. If you use
sizeof(node_t), you still pass the size of a node_t, which may be larger
or smaller than the size of a newnode_t. This would mean that bzero()
only zeroes part of the struct, or writes over its end. If you use
sizeof *pstr_node, you always pass in the right size: the size of the
object which pstr_node points at.
That means pointer variable to any type may be typecasted to (char *)
but *not* the viceversa ?
Click to expand...

Similarly to a void *, yes, except that void *s don't need casts. You
can assign any object pointer to a void *; you can also assign a void *
to any object pointer; but the latter only makes sense if the void *
contains the value of another pointer of the type assigned to. That is,
this is correct:

int *ip, i=4;
void *vp;

ip=&i;
vp=ip;
ip=NULL;
...
ip=vp;

and now ip again contains the address of i, as long as vp has not been
tampered with in the mean time. _This_, however, is not correct:

int *ip, i=4;
void *vp;
float *fp;

ip=&i;
vp=ip;
...
fp=vp;

Your compiler will probably not spot it, but you're indirectly assigning
an int pointer to a float pointer, which is not required to work.

Richard
 
M

Malcolm

Jason Curl said:
I have a question - I believed that the representation of char* and void*
are the same representation? If I'm right, then I don't see how the last
paragraph suits.
Click to expand...
I think that is actually right.
However if a machine came out that for some reason required pointers to
floating point types to carry around extra bits (maybe for FPU control) then
that part of the standard would be a dead letter and simply be ignored.
 
K

Keith Thompson

Malcolm said:
I think that is actually right.
However if a machine came out that for some reason required pointers to
floating point types to carry around extra bits (maybe for FPU control) then
that part of the standard would be a dead letter and simply be ignored.
Click to expand...

I doubt it. It's more likely that C implementations would add the
extra bits to both void* and char*, and ignore them unless they're
converted to float* (or double*, or ...).

A compiler that can't use char* as a generic pointer is at best
broken, and at worst not a C compiler, and it would break existing
code.
 
J

junky_fellow

To the compiler, yes, they're equivalent. But consider what happens if
you change pstr_node from a node_t to a newnode_t. If you use
sizeof(node_t), you still pass the size of a node_t, which may be larger
or smaller than the size of a newnode_t. This would mean that bzero()
only zeroes part of the struct, or writes over its end. If you use
sizeof *pstr_node, you always pass in the right size: the size of the
object which pstr_node points at.
Click to expand...
<snip>

I wrote a small test program to test your theory. But it doesn't seem
to
work.

#include <stdio.h>
struct Type1 {
int iVal1;
int iVal2;
char cVal3;
char cVal4;
};
struct Type2 {
long lVal1;
long lVal2;
int iVal3;
int iVal4;
char cVal5;
};
int main(void)
{
struct Type1 strType1;
struct Type2 strType2;
struct Type1 * pstrType1;

pstrType1 = &strType1;
printf("\nsizeof strType1 = %d\n",sizeof(struct Type1));
printf("sizeof *pstrType1 = %d\n",sizeof(* pstrType1));

pstrType1 = (struct Type1 *)&strType2;
/* change the underlying structure
*/
printf("sizeof strType1 = %d\n",sizeof(struct Type1));
printf("sizeof *pstrType1 = %d\n",sizeof(* pstrType1));

}

# a.out
sizeof strType1 = 12
sizeof *pstrType1 = 12
sizeof strType1 = 12
sizeof *pstrType1 = 12 <--- even after changing the underlying object
the size of object remains the same.


So, it seems to me that if a pointer "p" is declared as type "T" ( T
*p),
sizeof(T) or sizeof(*p) should always be same even though the
underlying object has been changed.

Also, when is the "sizeof" actually calculated ? Is it done at compile
time
or at run time ? Is this a function that is compiler built in ?
 
Z

Zoran Cutura

<snip>

I wrote a small test program to test your theory. But it doesn't seem
to
work.
Click to expand...

You missunderstood the above explanations.
#include <stdio.h>
struct Type1 {
int iVal1;
int iVal2;
char cVal3;
char cVal4;
};
struct Type2 {
long lVal1;
long lVal2;
int iVal3;
int iVal4;
char cVal5;
};
int main(void)
{
struct Type1 strType1;
struct Type2 strType2;
struct Type1 * pstrType1;

pstrType1 = &strType1;
printf("\nsizeof strType1 = %d\n",sizeof(struct Type1));
printf("sizeof *pstrType1 = %d\n",sizeof(* pstrType1));

pstrType1 = (struct Type1 *)&strType2;
/* change the underlying structure
*/
printf("sizeof strType1 = %d\n",sizeof(struct Type1));
printf("sizeof *pstrType1 = %d\n",sizeof(* pstrType1));

}

# a.out
sizeof strType1 = 12
sizeof *pstrType1 = 12
sizeof strType1 = 12
sizeof *pstrType1 = 12 <--- even after changing the underlying object
the size of object remains the same.
Click to expand...

The above statement was rather meant to say that when during development
of your program you recognize, that pstrType1 should rather be of type
"struct Type2 *" and you change the declaration/definition of the pointer
rather than the underlaying object, you don't have to check all the
sizeof(struct Type1) uses to see whether they need change or not.

OTOH some might argue that when you change the name of the pointer you
need to change it where ever it is used (so in the sizeofs this would
need work) but this can be done reliably by search and replace commands
of most editors, while you can't simply change every sizeof(TypeBlah).
So, it seems to me that if a pointer "p" is declared as type "T" ( T
*p),
sizeof(T) or sizeof(*p) should always be same even though the
underlying object has been changed.
Click to expand...

That is correct.
Also, when is the "sizeof" actually calculated ? Is it done at compile
time
or at run time ? Is this a function that is compiler built in ?
Click to expand...

sizeof is calculated at compile time and it ain't a function at
all. It's a operator as is "+" or "*".
 
M

Michael Mair

Zoran said:
sizeof is calculated at compile time and it ain't a function at
all. It's a operator as is "+" or "*".
Click to expand...

This is correct for C89.
In C99, we have variable length arrays; for these, the sizeof
operator actually must be evaluated at run time.

As for sizeof being an operator:
sizeof works either on an expression (sizeof myVariable,
sizeof *pMyVariable) or on a cast expression (sizeof (myType) for
some type myType); somehow, many people derive from the latter form
that the former has to be parenthesized, too. IMO, this leads to
the misunderstanding that sizeof were a function.


Cheers
Michael
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

Comparison of Integer and Pointer (that's supposed to be an Integer). Where did I go wrong? 0
Need help! Following code isnt working fully Comparison of integer and pointer 0
struct and pointer question 33
Strict aliasing rule: pointer to void vs. pointer to char and transitivity 3
pointer arithmetic 16
Setting array size with a variable - What does the C compiler do? 3
Portable (??) pointer alignment 27
Size of a compound literal array 1

Members online

No members online now.
Total: 1,975 (members: 0, guests: 1,975)
Robots: 115

Forum statistics

Threads
474,164
Messages
2,570,898
Members
47,439
Latest member
shasuze

Latest Threads

Top