size of pointer variables

[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 ...

[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.

--
bjrnove

[Ivan Vecerina]

<ju**********@yahoo.co.in> wrote in message
news:11**********************@g43g2000cwa.googlegr oups.com...

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 *) ? 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. 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 ...

hth-Ivan
--
http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form

[Richard Bos]

"Ivan Vecerina" <IN*************************@vecerina.com> wrote:

<ju**********@yahoo.co.in> wrote in message
news:11**********************@g43g2000cwa.googlegr oups.com...

Can the sizeof (char *) be different from sizeof(int *) or
sizeof (void *) ? char* and int* can be different, although I have never used
such a system.

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.

Yes. The same representation, as well.

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.

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

Richard

[Lawrence Kirby]

On Mon, 30 May 2005 01:38:01 -0700, bjrnove wrote:

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.

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

[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

[Lawrence Kirby]

On Mon, 30 May 2005 12:06:27 +0200, jacob navia wrote:

Pointers to different regions of memory can be different.
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.
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).

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

[Richard Bos]

jacob navia <ja***@jacob.remcomp.fr> wrote:

[ 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.
"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).

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

[Malcolm]

<ju**********@yahoo.co.in> wrote

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 *) ?
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.

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.

[junky_fellow]

Malcolm wrote:

<ju**********@yahoo.co.in> wrote

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 *) ?

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.

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.

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,

[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 ?

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).

--
bjrnove

[Richard Bos]

ju**********@yahoo.co.in wrote:

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 ?

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

[Jason Curl]

Malcolm wrote:

<ju**********@yahoo.co.in> wrote

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 *) ?

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.

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.

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.

[junky_fellow]

Richard Bos wrote:

ju**********@yahoo.co.in wrote:

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 ?
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.).

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

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

[Richard Bos]

ju**********@yahoo.co.in wrote:

Richard Bos wrote:

ju**********@yahoo.co.in wrote:

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

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

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.).

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

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.

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.

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

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

[Malcolm]

"Jason Curl" <j_********@motorola.com> wrote

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.

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.

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.

[Keith Thompson]

"Malcolm" <re*******@btinternet.com> writes:

"Jason Curl" <j_********@motorola.com> wrote

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.

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.

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.

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.

--
Keith Thompson (The_Other_Keith) 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.

[junky_fellow]

<snip>

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

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.

<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 ?

[Zoran Cutura]

ju**********@yahoo.co.in wrote:

<snip>

> Can you please specify why sizeof(*pstr_node) is better as compared
> to sizeof(struct node_t) ? I thought they both are equivalent.
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.

<snip>

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

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.
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.
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 ?

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

--
Z (zo**********@web.de)
"LISP is worth learning for the profound enlightenment experience
you will have when you finally get it; that experience will make you
a better programmer for the rest of your days." -- Eric S. Raymond

[Michael Mair]

Zoran Cutura wrote:

ju**********@yahoo.co.in wrote:

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 ?

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

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
--
E-Mail: Mine is an /at/ gmx /dot/ de address.