size of pointers

J

jacob navia

Richard Bos a écrit :
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.
 
R

Richard Heathfield

jacob navia said:

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

jacob navia

Richard Heathfield a écrit :
jacob navia said:




Elsewhere in this thread it has already been explained, and demonstrated in
at least two separate ways, why the above claim is incorrect.
No
 
C

Chris Torek

jacob navia said:
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, offset1> pair */
p2 = array2; /* p2 is, in effect, an <array2, offset2> pair */
... 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.)
 
C

Chris Torek

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

mark_bluemel

subramanian said:
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.
 
J

jacob navia

Richard Heathfield a écrit :
jacob navia said:




Yes. See Message-ID: <[email protected]> ff., and
Message-ID: <[email protected]>

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

mark_bluemel

jacob said:
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...
 
C

Chris Dollin

jacob said:
Richard Heathfield a écrit :

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

Richard Bos

jacob navia said:
Richard Bos a écrit :

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

Rather unlikely. But as you well know if you are competent and honest,
there are computers where addresses are not numbers at all, of any kind.
Addresses are consecutive integers starting with some base offset or
segment.

Bollocks, and if you were honest, you would admit it.

Richard
 
R

Richard Bos

jacob navia said:
Richard Heathfield a écrit :

How can you subtract two non integers and obtain an integer?

How many houses distance is there between yours and your next door
neighbour's neighbour's? Two. That's an integer. Is your home address an
integer? No, it's an address. Something like "11 Rue de Aveugle,
Nonsenseville, France". That's not an integer, _but_ the difference
between that address and another address within the same "object" (read:
street) is.

Richard
 
J

jacob navia

Richard Bos a écrit :
How many houses distance is there between yours and your next door
neighbour's neighbour's? Two. That's an integer. Is your home address an
integer? No, it's an address. Something like "11 Rue de Aveugle,
Nonsenseville, France". That's not an integer, _but_ the difference
between that address and another address within the same "object" (read:
street) is.

Richard

My address is the integer 41.

Offset from the start of the Maurice Ravel segment.

Consecutive memory locations are assigned consecutive integers
within the same segment (or "object", as you wish) of memory.

Obviously you think that if you do not call them integers but
"pointers" and hide some cloack of "mystery" around those
integers things will improve.

Be it. Your opinion is different than mine.
 
R

Richard Heathfield

jacob navia said:

My address is the integer 41.

If that is true, then mail addressed to:

Jacob Navia
41

will reach you. I am, however, not convinced that this is the case.

Offset from the start of the Maurice Ravel segment.

Then "Maurice Ravel" is part of your address, and it is not an integer.

Be it. Your opinion is different than mine.

This is not a matter of opinion. In C, pointers are not integers. They are
pointers. They can be converted into integers, but the C Standard does not
guarantee that this can be done without information loss.
 
J

jacob navia

Chris Dollin a écrit :
jacob navia wrote:




You have only to ask, and it shall be appeared.

(a) 4.7 - 3.7 = 1

This are boundary conditions, since float - float doesn't always
yield an integer. Pointer - pointer yields ALWAYS an integer,
if the operation is allowed of course.
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.

See above. CAN BE, but it is not ALWAYS.
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?




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.

I am not saying anthing else but that memory locations
within an object or "segment" are assigned consecutive
integers.

I am not implying that memory locations integers can be
divided or taken the square root, even if you CAN do that.

The house where I live in is the 41th of Maurice ravel street.
I *can* take the square root of 41, or even the cubic root
but that is not meaningful within the context of integers
assigned to consecutive addresses.
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.

Excuse me but when I come to the railway station I am assigned
an integer by the machine. That integer is my turn. The
employees call the integers aloud, then when I hear my integer
I go to the employee selling the tickets and do my transaction.

The same applies as with addresses. Integers are useful and used in
many contexts for many different things. You have 5 apples, and
4 oranges. Yes, you can't compare apples or oranges but you
COUNT them the same. Integers are abstractions, and when you
assign consecutive integers to memory locations you are using
the integers for a specific purpose. They remain integers,
that's all.

But let's stop this. It is absurd.

For you pointers aren't integers but whatever, something else.

Be it. OK.
 
R

Richard Heathfield

jacob navia said:

For you pointers aren't integers but whatever, something else.

Be it. OK.

Computers are not post-modernists; they rely on facts, not opinions. The C
Standard says:

"An integer may be converted to any pointer type. Except as previously
specified, the result is implementation-defined, might not be correctly
aligned, might not point to an entity of the referenced type, and might be
a trap representation."

and

"Any pointer type may be converted to an integer type. Except as previously
specified, the result is implementation-defined. If the result cannot be
represented in the integer type, the behavior is undefined. The result need
not be in the range of values of any integer type."

If pointers were integers, such conversions would not be necessary. The
usual arithmetic conversions would suffice.
 
J

jacob navia

Richard Heathfield a écrit :
jacob navia said:




If that is true, then mail addressed to:

Jacob Navia
41

will reach you. I am, however, not convinced that this is the case.





Then "Maurice Ravel" is part of your address, and it is not an integer.

This is the whole disagreement. Ok, it has costed us a certain time but
now we are at the heart of it.

No. The segment is not part of the integer that I am referring to.

In the case of my address, Maurice Ravel would not suffice since
there is ALSO a Maurice Ravel street in Montmagny, the next town
after Villetaneuse, where I live. And then, you have to take the
country in consideration etc.

In machine addresses, we have

segment:address, but... which segment?

Code segment, say.

Ok, but that is meaningful only within a certain process. And that is
meaningful only within a certain machine... etc etc.

Using the notation popularized with the web, we could also say
that

address://www.hearthfield.com/home/utilities/backup:CODE_SEGMENT:447766555

is an address. The meaning is to name a particular machine
in a particular configuration that runs the "backup" executable.

But WHICH part is necessary?
It depends on the context. You can say that within the context of a
process, the whole part until the second
':' is not necessary, because all that is implicit.

Within the context of a network, an address could be given a different
prefix.

If you take the prefix within the address, there is no end to the
prefixes you would need, and they change from context to context.

For this reason, I leave the "prefix" OUT of the integer, and retain
just the offset within the segment (obejct).
This is not a matter of opinion. In C, pointers are not integers. They are
pointers. They can be converted into integers, but the C Standard does not
guarantee that this can be done without information loss.

Yes, when they are converted to integers, the PREFIX can be lost (or
parts of it). That's why in some cases the address can't be
reconstructed. But if you just retain the integer part, you can
separate that from the non-integer prefix, and be done with it.
 
R

Richard Heathfield

jacob navia said:
Richard Heathfield a écrit :

Yes, when they are converted to integers, the PREFIX can be lost (or
parts of it). That's why in some cases the address can't be
reconstructed. But if you just retain the integer part, you can
separate that from the non-integer prefix, and be done with it.

Yes, it is true that if you ignore all the parts of a pointer that are not
an integer value, what remains (if anything) is an integer value.

Similarly, if you remove all the parts of a floating point value that are
not an integer value, what remains (if anything) is an integer value.

And if you remove all the parts of a coffee mug that are not an integer
value, what remains (if anything) is an integer value.

That does not mean that pointers, floating point values, and coffee mugs are
integers.
 
M

mark_bluemel

Richard said:
jacob navia said:


Yes, it is true that if you ignore all the parts of a pointer that are not
an integer value, what remains (if anything) is an integer value.

Similarly, if you remove all the parts of a floating point value that are
not an integer value, what remains (if anything) is an integer value.

And if you remove all the parts of a coffee mug that are not an integer
value, what remains (if anything) is an integer value.

That does not mean that pointers, floating point values, and coffee mugs are
integers.

"When I use a word," Humpty Dumpty said, in rather a scornful tone, "it
means just what I choose it to mean-neither more nor less."
"The question is, " said Alice, "whether you can make words mean so
many different things."
"The question is," said Humpty Dumpty. "which is to be master-that's
all."
 
C

CBFalconer

jacob said:
.... snip ...

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.

Those operations are only valid when all pointers point within the
same object.
 

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

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top