473,323 Members | 1,622 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,323 software developers and data experts.

size of pointers

I have been thinking that all pointers(to any obejct) have the same
size. The size of a pointer is the size of an int. This is beause a
memory location is addressed by an int. Is that right/wrong?

Dec 19 '06 #1
96 4087
"subramanian" <su**************@yahoo.comwrote:
I have been thinking that all pointers(to any obejct) have the same
size. The size of a pointer is the size of an int. This is beause a
memory location is addressed by an int. Is that right/wrong?
Entirely wrong, on all three counts.

Richard
Dec 19 '06 #2
machine word is 32bit

sizeof(char) == 1
sizeof(int) == 4
sizeof(char *) == 4
sizeof(int *) == 4

char array[30]= "abc"
char *p=array;

sizeof(array) == 30
sizeof(p) == 4
strlen(array) == strlen(p)
strlen(array) == 3
ÓÚ Mon, 18 Dec 2006 23:32:41 -0800£¬subramanianдµ½£º
I have been thinking that all pointers(to any obejct) have the same
size. The size of a pointer is the size of an int. This is beause a
memory location is addressed by an int. Is that right/wrong?
Dec 19 '06 #3
subramanian wrote:
I have been thinking that all pointers(to any obejct) have the same
size. The size of a pointer is the size of an int. This is beause a
memory location is addressed by an int. Is that right/wrong?
You are wrong on all counts. Pointers to different kinds of objects may
have different sizes; that size need not be an int; memory locations are
addressed by a pointer-to-object, not by an int.

Dec 19 '06 #4
iamgodk wrote:
machine word is 32bit
This is by no means guaranteed.
sizeof(char) == 1
OK
sizeof(int) == 4
This is by no means guaranteed.
sizeof(char *) == 4
This is by no means guaranteed.
sizeof(int *) == 4
This is by no means guaranteed.
>
char array[30]= "abc"
char *p=array;

sizeof(array) == 30
OK
sizeof(p) == 4
This is by no means guaranteed.
strlen(array) == strlen(p)
OK
strlen(array) == 3
OK

Please don't post information specific to your implementation as if it
were normative for the C programming language.
Dec 19 '06 #5
:)
some examples which are not normative may help
beginner to understand.

ÓÚ Tue, 19 Dec 2006 03:05:53 -0500£¬Martin Ambuhlдµ½£º
iamgodk wrote:
>machine word is 32bit

This is by no means guaranteed.
>sizeof(char) == 1

OK
>sizeof(int) == 4

This is by no means guaranteed.
>sizeof(char *) == 4

This is by no means guaranteed.
>sizeof(int *) == 4

This is by no means guaranteed.
>>
char array[30]= "abc"
char *p=array;

sizeof(array) == 30

OK
>sizeof(p) == 4

This is by no means guaranteed.
>strlen(array) == strlen(p)

OK
>strlen(array) == 3

OK

Please don't post information specific to your implementation as if it
were normative for the C programming language.
Dec 19 '06 #6

iamgodk wrote:
machine word is 32bit
On your implementation. I've worked on machines where words were 36
bits, machines where words were 16 bits and machines where words are 64
bits.
sizeof(char) == 1
sizeof(int) == 4
On your implementation perhaps. It doesn't have to be.
sizeof(char *) == 4
See above.
sizeof(int *) == 4
See above.

As I recall, on Pr1me systems, sizeof(char *) was 6 and sizeof(int *)
was 4. There were good architectural reasons for this.

As Martin A commented, you should not regard your specific C
implementation as definitive. My car is grey, has a diesel engine and 5
doors - does that mean anything with a petrol engine, blue and with 3
doors is not a car?

Dec 19 '06 #7

iamgodk wrote:
Tue, 19 Dec 2006 03:05:53 -0500£¬Martin Ambuhl£º
iamgodk wrote:
machine word is 32bit
This is by no means guaranteed.
sizeof(char) == 1
OK
sizeof(int) == 4
This is by no means guaranteed.
sizeof(char *) == 4
This is by no means guaranteed.
sizeof(int *) == 4
This is by no means guaranteed.
>
char array[30]= "abc"
char *p=array;

sizeof(array) == 30
OK
sizeof(p) == 4
This is by no means guaranteed.
strlen(array) == strlen(p)
OK
strlen(array) == 3
OK

Please don't post information specific to your implementation as if it
were normative for the C programming language.
some examples which are not normative may help
beginner to understand.
1) Please don't top-post.
2) Providing specific examples which reinforce the original posters
misconceptions will not help their understanding at all.

Dec 19 '06 #8
ÓÚ Tue, 19 Dec 2006 00:34:46 -0800£¬mark_bluemelдµ½£º
>
iamgodk wrote:
>Tue, 19 Dec 2006 03:05:53 -0500£¬Martin Ambuhl£º
iamgodk wrote:
machine word is 32bit

This is by no means guaranteed.

sizeof(char) == 1

OK

sizeof(int) == 4

This is by no means guaranteed.

sizeof(char *) == 4

This is by no means guaranteed.

sizeof(int *) == 4

This is by no means guaranteed.
char array[30]= "abc"
char *p=array;

sizeof(array) == 30

OK

sizeof(p) == 4

This is by no means guaranteed.

strlen(array) == strlen(p)

OK

strlen(array) == 3

OK

Please don't post information specific to your implementation as if it
were normative for the C programming language.
>some examples which are not normative may help
beginner to understand.

1) Please don't top-post.
2) Providing specific examples which reinforce the original posters
misconceptions will not help their understanding at all.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~
Thanks for your answer or the examples of the entire answer,
and I think your answer would help the the original posters:)

If you agree with your own opinion, please list all examples of
disadvantage about my post. Could you could u do that? Thanks.
Dec 19 '06 #9
iamgodk wrote:
ÓÚ Tue, 19 Dec 2006 00:34:46 -0800£¬mark_bluemelдµ½£º
iamgodk wrote:
Tue, 19 Dec 2006 03:05:53 -0500£¬Martin Ambuhl£º
iamgodk wrote:
machine word is 32bit
sizeof(int) == 4

This is by no means guaranteed.

sizeof(char *) == 4

This is by no means guaranteed.

sizeof(int *) == 4

This is by no means guaranteed.
If you agree with your own opinion, please list all examples of
disadvantage about my post. Could you could u do that? Thanks.
What's the point of saying:
machine word is 32bit
sizeof(int) == 4
sizeof(char *) == 4
sizeof(int *) == 4
?

What is anybody supposed to be able to learn from that?

--
pete
Dec 19 '06 #10
ÓÚ Tue, 19 Dec 2006 08:59:40 +0000£¬peteдµ½£º
ng:
machine word is 32bit
sizeof(int) == 4
sizeof(char *) == 4
sizeof(int *) == 4
?

What is anybody supposed to be able to learn from that?
somebody, like me, even learn something from yours:)
and I think that you think so too.

Can nobody not learn something from yours?
Dec 19 '06 #11
subramanian a écrit :
I have been thinking that all pointers(to any obejct) have the same
size. The size of a pointer is the size of an int. This is beause a
memory location is addressed by an int. Is that right/wrong?
No.

It is true that memory locations are integers, in some
machines a sequence of integers that refer to sequential
memory locations x, x+1, x+2, x+3, etc.

The "int" data type can be different from those integers,
much smaller, for instance. This is common in small
processors, where you have a big ROM and a small RAM amount.
There, pointers can be much bigger (24 bits or 32 bits) than
integers, since pointers must address the ROM.

Besides, not all pointers are equal, since you can have pointers to ram
that will fit in 16 bits, for instance, and pointers to ROM, that
need 24 bits, and pointers to some EPROM that will be 32 bits,
since the addresses of those areas were designed like that
in the circuit board.

Dec 19 '06 #12
subramanian wrote:
I have been thinking that all pointers(to any obejct) have the same
size.
Why have you been thinking that? It's not true.

(By "it's not true" I mean that it's not /required/ to be true
by the C Standard, and is (or was) /actually/ false on real
C implementations [1].)
The size of a pointer is the size of an int.
Not true (ditto).
This is beause a memory location is addressed by an int.
Not true (ditto) [2].
Is that right/wrong?
Yes, it's wrong.

[1] I recall Chris Torek describing one of the Primes where
char* was bigger than other* because the Prime was word-
addressed and extra room was needed in the char* for the
character offset.

[2] MS-DOS implementations had, I am told, multiple memory
models manifesting one where ints were 16 bits and pointers
were 32 bits.

--
Chris "desiring more M-words" Dollin
"Reaching out for mirrors hidden in the web." - Renaissance, /Running Hard/

Dec 19 '06 #13
iamgodk wrote:
>
ÓÚ Tue, 19 Dec 2006 08:59:40 +0000£¬peteдµ½£º
ng:
machine word is 32bit
sizeof(int) == 4
sizeof(char *) == 4
sizeof(int *) == 4
?

What is anybody supposed to be able to learn from that?

somebody, like me, even learn something from yours:)
and I think that you think so too.

Can nobody not learn something from yours?
The original post was:
"I have been thinking that all pointers(to any obejct) have the same
size. The size of a pointer is the size of an int. This is beause a
memory location is addressed by an int. Is that right/wrong?"

Your post seems to suggest that you think that
the original poster was right.
The original poster was wrong.

Pointers to different object types
may or may not have the same size.

What somebody can learn from me,
is that the original poster was wrong,
and that you were wrong to suggest otherwise.

--
pete
Dec 19 '06 #14
jacob navia <ja***@jacob.remcomp.frwrites:
subramanian a écrit :
>I have been thinking that all pointers(to any obejct) have the same
size. The size of a pointer is the size of an int. This is beause a
memory location is addressed by an int. Is that right/wrong?
No.

It is true that memory locations are integers, in some
machines a sequence of integers that refer to sequential
memory locations x, x+1, x+2, x+3, etc.
It is not *necessarily* true that memory locations are integers. In
most modern systems, machine addresses can be viewed as integers, but
the C standard is designed to support more complex memory models.
(For example, some systems use segmented addresses, where a machine
address consists of a segment number and an offset within the segment;
this is not necessarily meaningful as a single number. Arbitrarily
complex schemes are possible.)

As far as the C language is concerned, pointers are pointers and
integer are integers.
The "int" data type can be different from those integers,
much smaller, for instance. This is common in small
processors, where you have a big ROM and a small RAM amount.
There, pointers can be much bigger (24 bits or 32 bits) than
integers, since pointers must address the ROM.

Besides, not all pointers are equal, since you can have pointers to ram
that will fit in 16 bits, for instance, and pointers to ROM, that
need 24 bits, and pointers to some EPROM that will be 32 bits,
since the addresses of those areas were designed like that
in the circuit board.
You're talking about pointers to objects in different memory spaces;
that's not something that's directly supported by C, though some
compilers might support something like that as an extension. (Perhaps
something like "near" and "far" pointers?)

More relevantly, a pointer to one *type* may have a different size
than a pointer to another type. For example, a char* might be larger
than an int*. This shouldn't cause any problems for well-written
portable 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.
Dec 19 '06 #15
ÓÚ Tue, 19 Dec 2006 09:21:06 +0000£¬peteдµ½£º
iamgodk wrote:
>>
ng:
machine word is 32bit
sizeof(int) == 4
sizeof(char *) == 4
sizeof(int *) == 4
?

What is anybody supposed to be able to learn from that?

somebody, like me, even learn something from yours:)
and I think that you think so too.

Can nobody not learn something from yours?

The original post was:
"I have been thinking that all pointers(to any obejct) have the same
size. The size of a pointer is the size of an int. This is beause a
memory location is addressed by an int. Is that right/wrong?"

Your post seems to suggest that you think that
the original poster was right.
The original poster was wrong.

Pointers to different object types
may or may not have the same size.

What somebody can learn from me,
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
is that the original poster was wrong,
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
and that you were wrong to suggest otherwise.
What somebody can learn from you,
is that I must select new suitable cases for answer.
That's right. It's my fault. And then,
please remeber u have not reply to the original poster until now:)
Whoever are you, please give the original poster valuable answer
rather than give me the unilateralism answer for my post:)
Thanks.

Dec 19 '06 #16
jacob navia <ja***@jacob.remcomp.frwrote:
subramanian a écrit :
I have been thinking that all pointers(to any obejct) have the same
size. The size of a pointer is the size of an int. This is beause a
memory location is addressed by an int. Is that right/wrong?

No.

It is true that memory locations are integers,
Entirely wrong. Not all the world is a bitty-box, you know.

Richard
Dec 19 '06 #17
iamgodk <ia*****@b-star.cnwrites:
ÓÚ Tue, 19 Dec 2006 09:21:06 +0000£¬peteдµ½£º
[...]
>What somebody can learn from me,
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>is that the original poster was wrong,
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>and that you were wrong to suggest otherwise.
What somebody can learn from you,
is that I must select new suitable cases for answer.
That's right. It's my fault. And then,
please remeber u have not reply to the original poster until now:)
Whoever are you, please give the original poster valuable answer
rather than give me the unilateralism answer for my post:)
Thanks.
Learn to accept criticism.

--
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.
Dec 19 '06 #18
pete said:
iamgodk wrote:
<lots of junk - snipped>
What's the point of saying:
machine word is 32bit
sizeof(int) == 4
sizeof(char *) == 4
sizeof(int *) == 4
?

What is anybody supposed to be able to learn from that?
Not to trust iamgodk's advice about the C language. And that's a useful
lesson in itself.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Dec 19 '06 #19
jacob navia said:
subramanian a écrit :
>I have been thinking that all pointers(to any obejct) have the same
size. The size of a pointer is the size of an int. This is beause a
memory location is addressed by an int. Is that right/wrong?
No.

It is true that memory locations are integers,
No, it isn't.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Dec 19 '06 #20
ÓÚ Tue, 19 Dec 2006 09:48:39 +0000£¬Keith Thompsonдµ½£º
iamgodk <ia*****@b-star.cnwrites:
>ÓÚ Tue, 19 Dec 2006 09:21:06 +0000£¬peteдµ½£º
[...]
>>What somebody can learn from me,
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>is that the original poster was wrong,
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>and that you were wrong to suggest otherwise.
What somebody can learn from you,
is that I must select new suitable cases for answer.
That's right. It's my fault. And then,
please remeber u have not reply to the original poster until now:)
Whoever are you, please give the original poster valuable answer
rather than give me the unilateralism answer for my post:)
Thanks.

Learn to accept criticism.
You are right. Thanks for your advice.
Dec 19 '06 #21
ÓÚ Tue, 19 Dec 2006 09:50:19 +0000£¬Richard Heathfieldдµ½£º
pete said:
>iamgodk wrote:

<lots of junk - snipped>
>What's the point of saying:
machine word is 32bit
sizeof(int) == 4
sizeof(char *) == 4
sizeof(int *) == 4
?

What is anybody supposed to be able to learn from that?

Not to trust iamgodk's advice about the C language. And that's a useful
lesson in itself.
anybody access the web "mindspring.com", and they will discover
"mindspring.com" is related with "earthlink.net".
"see.sig.invalid" may be the same.
Dec 19 '06 #22
Richard Heathfield a écrit :
jacob navia said:

>>subramanian a écrit :
>>>I have been thinking that all pointers(to any obejct) have the same
size. The size of a pointer is the size of an int. This is beause a
memory location is addressed by an int. Is that right/wrong?

No.

It is true that memory locations are integers,


No, it isn't.
Yes they are

:-)
Dec 19 '06 #23
Richard Bos a écrit :
jacob navia <ja***@jacob.remcomp.frwrote:

>>subramanian a écrit :
>>>I have been thinking that all pointers(to any obejct) have the same
size. The size of a pointer is the size of an int. This is beause a
memory location is addressed by an int. Is that right/wrong?

No.

It is true that memory locations are integers,


Entirely wrong. Not all the world is a bitty-box, you know.

Richard
Yes, you should take that to heart
Dec 19 '06 #24
iamgodk said:
? Tue, 19 Dec 2006 09:50:19 +0000?Richard Heathfield???
>pete said:
<snip>
>>>
What is anybody supposed to be able to learn from that?

Not to trust iamgodk's advice about the C language. And that's a useful
lesson in itself.

anybody access the web "mindspring.com", and they will discover
"mindspring.com" is related with "earthlink.net".
"see.sig.invalid" may be the same.
If you think I'm a sock-puppet for pete, think again, and look for
counter-evidence that might disprove your claim. It will be surprisingly
easy to find.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Dec 19 '06 #25
jacob navia said:
Richard Heathfield a écrit :
>jacob navia said:

>>>subramanian a écrit :

I have been thinking that all pointers(to any obejct) have the same
size. The size of a pointer is the size of an int. This is beause a
memory location is addressed by an int. Is that right/wrong?
No.

It is true that memory locations are integers,


No, it isn't.
Yes they are
Here's a counter-example:

#include <stdio.h>

int main(void)
{
int i = 42;
void *p = &i;
printf("[%p]\n", p);
return 0;
}

Output:

[DS:0400]

Are you arguing that DS:0400 is an integer?

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Dec 19 '06 #26
Richard Heathfield a écrit :
jacob navia said:

>>Richard Heathfield a écrit :
>>>jacob navia said:

subramanian a écrit :
>I have been thinking that all pointers(to any obejct) have the same
>size. The size of a pointer is the size of an int. This is beause a
>memory location is addressed by an int. Is that right/wrong?
>

No.

It is true that memory locations are integers,
No, it isn't.

Yes they are


Here's a counter-example:

#include <stdio.h>

int main(void)
{
int i = 42;
void *p = &i;
printf("[%p]\n", p);
return 0;
}

Output:

[DS:0400]

Are you arguing that DS:0400 is an integer?
Of course it is an integer, it is the 0400th integer of
the sequence 0... sizeof data segment!!!

Can't you read?

DS:0400 is an integer offset within the
data segment. As I explained in my message, there can
be different memory areas, and pointers can be
of different sizes depending of the memory area.

But you take out a sentence of my message and
put it in another special context just because
you have nothing else to do this morning than
starting again those endless polemic stuff that you
like so much
0400 is a floating point number?

Or you interpret that as a complex number maybe?

Dec 19 '06 #27
jacob navia wrote:
subramanian a écrit :
>I have been thinking that all pointers(to any obejct) have the
same size. The size of a pointer is the size of an int. This is
beause a memory location is addressed by an int. Is that
right/wrong?

No.

It is true that memory locations are integers, in some
machines a sequence of integers that refer to sequential
memory locations x, x+1, x+2, x+3, etc.
This is also very wrong. An elementary counter example is the
segmented X86 memory.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
Dec 19 '06 #28
jacob navia <ja***@jacob.remcomp.frwrites:
Richard Heathfield a écrit :
>jacob navia said:
>>>Richard Heathfield a écrit :

jacob navia said:
[...]
>>>>>It is true that memory locations are integers,

No, it isn't.

Yes they are
Here's a counter-example:
#include <stdio.h>
int main(void)
{
int i = 42;
void *p = &i;
printf("[%p]\n", p);
return 0;
}
Output:
[DS:0400]
Are you arguing that DS:0400 is an integer?

Of course it is an integer, it is the 0400th integer of
the sequence 0... sizeof data segment!!!

Can't you read?
0400 is an integer.

DS:0400 is not an integer.

Integers are not pointers. Pointers are not integers. This is
fundamental to an understanding of C.
DS:0400 is an integer offset within the
data segment. As I explained in my message, there can
be different memory areas, and pointers can be
of different sizes depending of the memory area.
Not in standard C; see my other followup.

--
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.
Dec 19 '06 #29
2006-12-19 <45***********@mindspring.com>,
pete wrote:
What's the point of saying:
machine word is 32bit
sizeof(int) == 4
sizeof(char *) == 4
sizeof(int *) == 4
?

What is anybody supposed to be able to learn from that?
That you can do certain things on a VAX that you might not be able to do
on some other architectures where these assumptions don't hold?
Dec 19 '06 #30
2006-12-19 <45**********************@news.orange.fr>,
jacob navia wrote:
Richard Heathfield a écrit :
>jacob navia said:

>>>Richard Heathfield a écrit :

jacob navia said:

>subramanian a écrit :
>
>
>>I have been thinking that all pointers(to any obejct) have the same
>>size. The size of a pointer is the size of an int. This is beause a
>>memory location is addressed by an int. Is that right/wrong?
>>
>
>No.
>
>It is true that memory locations are integers,
No, it isn't.
Yes they are


Here's a counter-example:

#include <stdio.h>

int main(void)
{
int i = 42;
void *p = &i;
printf("[%p]\n", p);
return 0;
}

Output:

[DS:0400]

Are you arguing that DS:0400 is an integer?

Of course it is an integer, it is the 0400th integer of
the sequence 0... sizeof data segment!!!

Can't you read?

DS:0400 is an integer offset within the
data segment. As I explained in my message, there can
be different memory areas, and pointers can be
of different sizes depending of the memory area.

But you take out a sentence of my message and
put it in another special context just because
you have nothing else to do this morning than
starting again those endless polemic stuff that you
like so much
0400 is a floating point number?

Or you interpret that as a complex number maybe?
He meant the whole of "DS:0400" is not an integer.

For an example you might be less able to explain away... in what way is
"(SPP:0000 :1aefRMA_INTPTRMJK 070591 :10320:4:28)" an integer? Now, it
does contain integers, but it's not at all obvious how they're related
to offsets within physical memory, or to fields within the 16-byte
pointer object.
Dec 19 '06 #31
jacob navia said:
Richard Heathfield a écrit :
>jacob navia said:
<snip>
>Are you arguing that DS:0400 is an integer?

Of course it is an integer,
I rest my case.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Dec 19 '06 #32
subramanian wrote:
>
I have been thinking that all pointers(to any obejct) have the same
size. The size of a pointer is the size of an int. This is beause a
memory location is addressed by an int. Is that right/wrong?
As pointed out elsethread, this is wrong on all counts.

Consider the 16-bit segmented world of "real mode" x86 programming.
In such an environment, you may have:

sizeof(int) == 2
sizeof(char near *) == 2
sizeof(char far *) == 4
sizeof(char *) == either 2 or 4, depending on compiler options

(Note, "near" and "far" are not standard. However, you are likely
to come across such extensions in the 16-bit x86 world.)

Also, in the world of 32-bit "protected mode" x86 programming, you
might have:

sizeof(int) == 4
sizeof(char *) == 4
sizeof(char far *) == 6

I have no idea what you might get in the 64-bit x86 world, but I
would suspect that there are 8-byte integer types as well as 8-byte
pointer types, in addition to 4-byte integer and pointer types.

Finally, there are CPUs in which integers and pointers are stored
in different registers while being used by the CPU. (For example,
the 68000 line of CPUs has a set of "D" registers for data, and a
separate set of "A" registers for addresses/pointers.)

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

Dec 19 '06 #33
iamgodk <ia*****@b-star.cnwrote:
ÓÚ Tue, 19 Dec 2006 09:21:06 +0000£¬peteдµ½£º
What somebody can learn from me,
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
is that the original poster was wrong,
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
and that you were wrong to suggest otherwise.
What somebody can learn from you,
is that I must select new suitable cases for answer.
No. What they can learn - and what _you_ _should_ learn - is that no
single specific case is an answer to the OP's question. Any single case
constitutes misinformation. The answer to the OP's question is simple:
no, the sizes of ints and of the various kinds of object pointers are
_not_ necessarily the same, because pointers are _not_ integers.
Whoever are you, please give the original poster valuable answer
This has already been done.
rather than give me the unilateralism
That word does not mean what you think it does.

Richard
Dec 19 '06 #34
jacob navia <ja***@jacob.remcomp.frwrote:
Richard Bos a écrit :
jacob navia <ja***@jacob.remcomp.frwrote:
>It is true that memory locations are integers,
Entirely wrong. Not all the world is a bitty-box, you know.

Yes, you should take that to heart
I'm not the one pretending that all computers work like the only ones
I've had experience with, you know. You are.

Richard
Dec 19 '06 #35
"Richard Bos" <rl*@hoekstra-uitgeverij.nlwrote in message
"subramanian" <su**************@yahoo.comwrote:
>I have been thinking that all pointers(to any obejct) have the same
size. The size of a pointer is the size of an int. This is beause a
memory location is addressed by an int. Is that right/wrong?

Entirely wrong, on all three counts.
Almost right. But actually, as you say, wrong.

Most computers have a flat memory and no funny things like 8 bit chars
implemented on top of 32-bit machine bytes. So all pointers are of the same
size. However you get a few wierdos - the one I mentioned is a case in
point. On one of Chris Torek's machines char *s are tagged with an extra two
bits, so are slightly bigger than other pointers. void *s, are, of course,
also bigger.

Most computer s amke no distinction between address registers, which in C
terms hold pointers, and integer pointers. Until 64 bit machines came along,
int was always the natural register size, so pointers and int were generally
the same size. Even now, some foolish people refuse to join my campaign for
64 bit ints, and we migh see 64-bit pointers and 32 bit ints becoming
common.

Interconvertibility between pointers and ints is not, however, an advantage
of 64 bit ints, as far as I can identify.

Addresses are usually integers - bytes are whole things - but the OP would
have to classify what he means by "addressed by an int". As Richard
Heathfield pointed out, the memory might also be segmented.

--
www.personal.leeds.ac.uk/~bgy1mm
freeware games to download.
Richard

Dec 19 '06 #36
"Malcolm" <re*******@btinternet.comwrote in message
news:sN******************************@bt.com...
"Richard Bos" <rl*@hoekstra-uitgeverij.nlwrote in message
>"subramanian" <su**************@yahoo.comwrote:
>>I have been thinking that all pointers(to any obejct) have the same
size. The size of a pointer is the size of an int. This is beause a
memory location is addressed by an int. Is that right/wrong?

Entirely wrong, on all three counts.
Almost right. But actually, as you say, wrong.

Most computers have a flat memory and no funny things like ...
Most is not good enough. What you're saying is that your statement is
true on any systems for which it is true -- circular logic. In reality,
a statement is false if there is a single counter-example, and there are
plenty of counter-examples to yours.

Now, _you_ may not care about any of the hundreds of platforms C runs on
besides your i386 Linux/Win32 box, but if you write code with those
flawed assumptions that's all your code will be guaranteed to run on.
If you want _portable_ code, you accept that all the world is not a
VAX^H^H^Hi386 and write your code accordingly.

Trying to push your closed-minded views about what platforms matter is
not going to go over well in a forum filled with people who make their
living writing code for platforms you have deemed irrelevant.

S

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
--
Posted via a free Usenet account from http://www.teranews.com

Dec 20 '06 #37
"Malcolm" <re*******@btinternet.comwrites:
"Richard Bos" <rl*@hoekstra-uitgeverij.nlwrote in message
>"subramanian" <su**************@yahoo.comwrote:
>>I have been thinking that all pointers(to any obejct) have the same
size. The size of a pointer is the size of an int. This is beause a
memory location is addressed by an int. Is that right/wrong?

Entirely wrong, on all three counts.
Almost right. But actually, as you say, wrong.

Most computers have a flat memory and no funny things like 8 bit chars
implemented on top of 32-bit machine bytes. So all pointers are of the same
size.
So you have a choice. You can think in terms of a memory model
("pointers are integers") that happens to be valid for *most*
machines. Or you can think in terms of a more general memory model
("pointers are pointers; integers are integers") that is valid for
*all* machines.

Since this newsgroup discusses a programming language, not some
limited (though large) subset of existing hardware, I choose the
latter. In the context of general C programming, the assumption that
pointers are integers is not only untrue; it's not particularly
helpful in understanding what's going on.

--
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.
Dec 20 '06 #38
Thas wrong - Pointers are of the type "unsigned integers".

Onkar
subramanian wrote:
I have been thinking that all pointers(to any obejct) have the same
size. The size of a pointer is the size of an int. This is beause a
memory location is addressed by an int. Is that right/wrong?
Dec 20 '06 #39
onkar said:
>
subramanian wrote:
>I have been thinking that all pointers(to any obejct) have the same
size. The size of a pointer is the size of an int. This is beause a
memory location is addressed by an int. Is that right/wrong?

Thas wrong
You're correct to claim that he's wrong...
- Pointers are of the type "unsigned integers".
....but incorrect to make this claim that pointers have unsigned integer
type. In fact, they have pointer type. See 3.1.2.5 Types (or 6.2.5 Types in
C99).

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Dec 20 '06 #40
Richard Bos a écrit :
jacob navia <ja***@jacob.remcomp.frwrote:

>>Richard Bos a écrit :
>>>jacob navia <ja***@jacob.remcomp.frwrote:
It is true that memory locations are integers,

Entirely wrong. Not all the world is a bitty-box, you know.

Yes, you should take that to heart


I'm not the one pretending that all computers work like the only ones
I've had experience with, you know. You are.

Richard
Yes, there could be computers where addresses are complex numbers
Or floating point numbers.

So you would access to the address 4677655.2 ...

Addresses are consecutive integers starting with some base offset or
segment. The segment can be implicit, or ignored, etc. There are
many variations, but in ALL cases they are integers numbering
consecutive memory locations.

Dec 20 '06 #41
jacob navia said:

<snip>
Addresses are consecutive integers starting with some base offset or
segment.
Elsewhere in this thread it has already been explained, and demonstrated in
at least two separate ways, why the above claim is incorrect.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Dec 20 '06 #42
Richard Heathfield a écrit :
jacob navia said:

<snip>

>>Addresses are consecutive integers starting with some base offset or
segment.


Elsewhere in this thread it has already been explained, and demonstrated in
at least two separate ways, why the above claim is incorrect.
No
Dec 20 '06 #43
jacob navia said:
Richard Heathfield a écrit :
>jacob navia said:

<snip>

>>>Addresses are consecutive integers starting with some base offset or
segment.


Elsewhere in this thread it has already been explained, and demonstrated
in at least two separate ways, why the above claim is incorrect.
No
Yes. See Message-ID: <I8******************************@bt.comff., and
Message-ID: <sl*******************@rlaptop.random.yi.org>

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Dec 20 '06 #44
>jacob navia said:
>Addresses are consecutive integers starting with some base offset or
segment.
In article <E_*********************@bt.com>
Richard Heathfield <rj*@see.sig.invalidwrote:
>Elsewhere in this thread it has already been explained, and demonstrated in
at least two separate ways, why the above claim is incorrect.
C's array model, however, requires that each object with an
address (i.e., each non-"register" object whose address is
taken at some point) *appear* to work that way.

The peculiar thing about this is that the "integer part", as it
were, is not necessarily unique, and in fact is usually non-unique
if you access it in the portable way:

T1 *p1, array1[N];
T2 *p2, array2[N];
size_t o1, o2;

p1 = array1; /* p1 is, in effect, an <array1, offset1pair */
p2 = array2; /* p2 is, in effect, an <array2, offset2pair */
... code that adjusts p1 and p2, e.g., *p1++ and the like ...

o1 = p1 - array1; /* finds <offset1*/
o2 = p2 - array2; /* finds <offset2*/

It is not at all unusual for o1 and o2 to be equal; in fact, it is
usually the case that o1 and/or o2 are equal to some other integer
computed from some other pointer by subtracting that pointer's
base.

The values of offset1 and offset2 are integral, and initially both
are 0 (because p1==&array1[0] and p2==&array2[0]). Each "p1++" or
"p2++" increments the corresponding offset, giving rise to the
"consecutive integers" Jacob Navia described.

Interestingly, C's bytes-of-object model -- in which the address
of any object can be converted to "unsigned char *" and the
object's underlying byte-at-a-time representation extracted --
allows one to break up these whole integers into "fractional
integers", in a sense. If, e.g., sizeof(T1) is 4, then when
offset1 is 5 (so that p1==&array1[5]), if we do:

unsigned char *q0, *q1;
size_t x;

q0 = (unsigned char *)&array[0];
q1 = (unsigned char *)p1;
x = q1 - q0;

we are guaranteed to get x == 20. More generally, here, if we
compute o1 as above, we get x == o1 * sizeof(*p1).

On machines like the 64-bit-word but 8-bit-"char" Cray, this
requires that pointer arithmetic compile to some extra-fancy
machine code, in some cases. In particular, q1 - q0 is not
just plain subtraction. The machine code for computing x is
effectively the same as that for:

x = ((int)q1 & 0xffffffffffff) - ((int)q0 & 0xffffffffffff) * 8
+ (((int)q1 >48) - ((int)q0 >48));

(On more conventional machines, computing o1 and o2 from p1 and p2
implies a division step, where the result of the division never
has a remainder. This allows compilers to use shortcuts in most
cases on most machines. I believe I was the one who convinced RMS
to put in that feature internally, when I pointed out that an early
gcc was generating a full-blown divide for pointer subtraction.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
Dec 20 '06 #45
In article <em*********@news3.newsguy.comI wrote, in part:
>The [Cray] machine code for [byte pointer subtraction] is
effectively the same as that for:

x = ((int)q1 & 0xffffffffffff) - ((int)q0 & 0xffffffffffff) * 8
+ (((int)q1 >48) - ((int)q0 >48));
Of course, that should be parenthesized slightly more:

x = (((int)q1 & 0xffffffffffff) - ((int)q0 & 0xffffffffffff)) * 8
+ (((int)q1 >48) - ((int)q0 >48));

since the goal here is to convert "machine word offset" (subtraction
of lower 48 bits of each pointer) into "byte offset" (multiply by
8 bytes per word), and then add the difference in byte offsets
(which may be negative if q1 >48 is less than q0 >48).

(It is safe to use either signed or unsigned int since the byte
offset field in the upper 16 bits is limited in range to [0..7].)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
Dec 20 '06 #46

subramanian wrote:
I have been thinking that all pointers(to any obejct) have the same
size. The size of a pointer is the size of an int. This is beause a
memory location is addressed by an int. Is that right/wrong?
It's wrong. It may be true for some specific systems, but it is not a
universal truth. Here's a detailed counter example.

I used to work on Prime 50-series systems.

Primes had a segmented memory structure and basic addressing was to the
half-word (16-bit unit) level. (Prime's architecture was originally
based on 16-bit machine words...)

So a basic pointer was 32-bits long :_
One bit was a "fault bit" (don't ask)
3 bits(IIRC) were a "ring number" (to do with security levels)
12 bits were a segment number
16-bits were the offset of the relevant half-word in the segment.
Pointer arithmetic traditionally wrapped within segments - incrementing
a pointer at the top of a segment would _not_ take you to the beginning
of the next, but to the beginning of the current one.

For byte (8-bit) addressing, a 48-bit pointer was used, which added a
whole 16-bits to represent byte 0 or 1 of the 16-bit half-word.

So on Prime - sizeof(char *) was 6, sizeof(void *) was 6, and
sizeof(int *) etc were 4. I think sizeof(int) was 4, but it may have
been 2.

The later versions of C on Prime "cheated" by using the fault bit of a
32-bit address to indicate byte 0 or 1 of the half-word, allowing all
pointer types to be the same size. But they still were not integers.

Dec 20 '06 #47
Richard Heathfield a écrit :
jacob navia said:

>>Richard Heathfield a écrit :
>>>jacob navia said:

<snip>

Addresses are consecutive integers starting with some base offset or
segment.
Elsewhere in this thread it has already been explained, and demonstrated
in at least two separate ways, why the above claim is incorrect.

No


Yes. See Message-ID: <I8******************************@bt.comff., and
Message-ID: <sl*******************@rlaptop.random.yi.org>
How can you subtract two non integers and obtain an integer?

Can you explain that with all your rubbish???

Pointer subtraction:

pointer - pointer --integer

pointer + integer --pointer

pointer - integer --pointer

If pointer would NOT be of integer type this could
never work.
Dec 20 '06 #48

jacob navia wrote:
How can you subtract two non integers and obtain an integer?

Can you explain that with all your rubbish???

Pointer subtraction:

pointer - pointer --integer

pointer + integer --pointer

pointer - integer --pointer

If pointer would NOT be of integer type this could
never work.
Nonsense.

Please see my discussion of pointers on Prime 50 series (which had a
perfectly compliant - AKAIK - C implementation) elsewhere in the thread
for a detailed counter-example. No-one with a reasonable definition of
the term "integer" (it is possible you have your own definition) could
describe a {fault bit, ring, segment, offset} tuple as an integer, but
that's what the system used for pointers and the operations you list
above had a well-defined meaning.

http://www.plethora.net/~seebs/c/10com.html - notably the 10th...

Dec 20 '06 #49
jacob navia wrote:
Richard Heathfield a écrit :
>jacob navia said:

>>>Richard Heathfield a écrit :

jacob navia said:

<snip>

>Addresses are consecutive integers starting with some base offset or
>segment.
Elsewhere in this thread it has already been explained, and demonstrated
in at least two separate ways, why the above claim is incorrect.
No


Yes. See Message-ID: <I8******************************@bt.comff., and
Message-ID: <sl*******************@rlaptop.random.yi.org>

How can you subtract two non integers and obtain an integer?
You have only to ask, and it shall be appeared.

(a) 4.7 - 3.7 = 1

The difference of two non-integer numeric values can be an
integer. (1 = 1.0; they are the same /value/. We're not
talking floating-point here.)

(b) (7+4i) - (3+4i) = 4

The difference of two complex integers can be a plain
ordinary integer. (The complex value (4+0i) is the
same value as the integer 4.)

(c) (x^2 + 2x + 1) - (x^2 + 2x) = 1

The difference between two polynomials can be an integer.
Can you explain that with all your rubbish???
Look like it. And we don't even need all of anyone's
rubbish. In fact I've made do with none. Do I get a
prezzie?
pointer - pointer --integer
pointer + integer --pointer
pointer - integer --pointer

If pointer would NOT be of integer type this could
never work.
False.

Also, conspicuous by its absence is `pointer + pointer`. If
pointers were integers, this would be well-defined and
meaningful. It isn't and they aren't. /Some/ aspects of
pointers can be represented as integers.

You can usefully think of pointers as `base + integer`.
Each `base` is a unique symbol - each object allocation
(be it mallocation, automatic, or static) creates a new
base. The pointer rules ensure that a legal pointer value
has exactly one base in it [1].

Just because some implementations work hard to represent
base values as integers (well, integer-like bit-patterns)
doesn't mean that bases /are/ integers. After all, they
also work hard to represent floating-point numbers, and
sets, and strings, and functions, as bit-pattern-like
integers.

[1] I suspect this analysis is too simplistic: does one
base suffice to handle nested structs, for example?
But I think it will do for now.

--
Chris "HO. HO. HO." Dollin
"Who are you? What do you want?" /Babylon 5/

Dec 20 '06 #50

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

Similar topics

12
by: Ellarco | last post by:
``Opaque-pointer representing the ID of an object. struct _objID; typedef struct _objID * objectID;'' Hi again. Im using an api that defines an objectID type. The above represents the extent...
11
by: Linny | last post by:
Hi, I need some help in declaring an array of pointers to array of a certain fixed size. I want the pointers to point to arrays of fixed size only (should not work for variable sized arrays of the...
79
by: syntax | last post by:
what is the size of a pointer? suppose i am writing, datatype *ptr; sizeof(ptr); now what does this sizeof(ptr) will give? will it give the size of the
6
by: Carl-Olof Almbladh | last post by:
Already in the 1st edition of the "White book", Kerigham and Ritchie states the "C is a general purpose language". However, without what is usually called "assumed size arrays" and built-in...
19
by: junky_fellow | last post by:
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...
38
by: maadhuu | last post by:
does it make sense to find the size of a function ??? something like sizeof(main) ??? thanking you ranjan.
33
by: siliconwafer | last post by:
What is size of pointer in C on DOS? is it sizeof(int ) or size of (long int)? If this ans is present in FAQ pls direct me to tht ouestion
11
by: subramanian100in | last post by:
Given that the sizes of pointers to different data types(built-in or structures) can be different, though malloc returns a void *, it is assigned to any pointer type. The language allows it. From...
33
by: Adam Chapman | last post by:
Hi, Im trying to migrate from programming in Matlab over to C. Im trying to make a simple function to multiply one matrix by the other. I've realised that C can't determine the size of a 2d...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
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...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
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...
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....

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.