«

A pointer cannot hold a non_address value, but what is the difference
of the representation of address with an ordinary integer? do address
have some special format to separate with common integers?

wrote:
> A pointer cannot hold a non_address value,

That depends on the architecture, on many common systems a pointer can
hold ant numerical value that fits within its width.

> but what is the difference
> of the representation of address with an ordinary integer? do address
> have some special format to separate with common integers?

Again, the answer is architecture dependant. Systems with segmented
address spaces have special pointer formats, those with flat address
spaces need not.

--
Ian Collins

Ian Collins <ian-> writes:

> wrote:
>> A pointer cannot hold a non_address value,
>
> That depends on the architecture, on many common systems a pointer can
> hold ant numerical value that fits within its width.
>
>> but what is the difference
>> of the representation of address with an ordinary integer? do address
>> have some special format to separate with common integers?
>
> Again, the answer is architecture dependant. Systems with segmented
> address spaces have special pointer formats, those with flat address
> spaces need not.

Those "special pointers" are still the "address".

Richard <rgrdev_@gmail.com> writes:

> Ian Collins <ian-> writes:
>
>> wrote:
>>> A pointer cannot hold a non_address value,

That is not a well-defined term. Pointers can hold values that you
can't use to access an object. For example,: int i; int *ip = &i + 1;
is OK but you can't access *ip. That might be what you mean by a
non-address value though I would call it, informally, an invalid
pointer.

>> That depends on the architecture, on many common systems a pointer can
>> hold ant numerical value that fits within its width.
>>
>>> but what is the difference
>>> of the representation of address with an ordinary integer? do address
>>> have some special format to separate with common integers?
>>
>> Again, the answer is architecture dependant. Systems with segmented
>> address spaces have special pointer formats, those with flat address
>> spaces need not.
>
> Those "special pointers" are still the "address".

Yes, Ian Collins said so in the message you seem to be replying to. I
don't think anyone (serious) disputes the fact that valid object
pointers store addresses.

The OP raised two issues: "non-address values" and the degree to which
addresses are similar in representation to integers. Both of these
points have been answered at least to some extent, though I thought it
worth adding a bit more.

--
Ben.

Malcolm McLean wrote:
>
> <> wrote in message news:
>> A pointer cannot hold a non_address value, but what is the difference
>> of the representation of address with an ordinary integer? do address
>> have some special format to separate with common integers?
>>
> Normally no, pointers are the same width as the natural integer type for
> the machine, and are just integers internally.

Malcolm, you KNOW that this is wrong. At least, you should do by now.

> However this doesn't always hold true. The most familiar exception is
> the old x86 series of chips found in early PCs. Addresses were segment +
> offset.

Although pointers were not always segment+offset. When they are (I know
there is still 8086 code out there) the pointer is larger than the
natural integer type.

Not all processors have only one natural integer type (registers one
size, data bus another size). I've used one where the address registers
and data bus were 16 bits but the accumulator was 32 bits. I've also
read specs for even more surprising combinations in the past.

It is now common once more for pointers to by larger than the int type,
for very good reasons.
--
Flash Gordon

Richard wrote:
> Ian Collins <ian-> writes:
>
>> wrote:
>>> A pointer cannot hold a non_address value,

>> That depends on the architecture, on many common systems a pointer can
>> hold ant numerical value that fits within its width.
>>
>>> but what is the difference
>>> of the representation of address with an ordinary integer? do address
>>> have some special format to separate with common integers?

>> Again, the answer is architecture dependant. Systems with segmented
>> address spaces have special pointer formats, those with flat address
>> spaces need not.
>
> Those "special pointers" are still the "address".
>
Did I say otherwise?

--
Ian Collins

Malcolm McLean wrote:
>
> "Flash Gordon" <> wrote in message
> news:...
>> Malcolm McLean wrote:
>>>
>>> <> wrote in message news:
>>>> A pointer cannot hold a non_address value, but what is the difference
>>>> of the representation of address with an ordinary integer? do address
>>>> have some special format to separate with common integers?
>>>>
>>> Normally no, pointers are the same width as the natural integer type
>>> for the machine, and are just integers internally.
>>
>> Malcolm, you KNOW that this is wrong. At least, you should do by now.
>>
> "Normally" is code for "on Intel PCs".

Ah, so by "Normally" you mean the minority of cases. Every PC I've ever
come across has had more processors not based on the X86 architecture
(or its successors) than it has processors based on the x86
architecture. Then there are all the things which are not PCs.

> From Wikipedia:
>
> Intel has extensively documented the Itanium instruction set and

<snip>

> Sounds like the natural integer size is 64 bits. As is the natural
> integer size. If your C compiler doesn't provide 64-bit ints, complain
> and join my campaign to pressurise them to do so.

Intel recommend using a 32 bit int on the IA64. Therefore Intel consider
32 bits to be a natural size of the architecture. What makes you think
you know Intel architectures better than Intel do.
--
Flash Gordon

Flash Gordon <> writes:
[...]
> Not all processors have only one natural integer type (registers one
> size, data bus another size). I've used one where the address
> registers and data bus were 16 bits but the accumulator was 32
> bits. I've also read specs for even more surprising combinations in
> the past.
>
> It is now common once more for pointers to by larger than the int
> type, for very good reasons.

A perhaps interesting data point: On all the C implementations I've
used (on which I've checked this), all pointer types are the same size
as long int. In some cases, this is the same size as int; in others,
long int is twice the size of int.

I do not suggest that this is "normal", just that it seems to be
common. I'm well aware that there are a lot of systems I haven't used
where this doesn't apply.

--
Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Malcolm McLean wrote:
>
> "Flash Gordon" <> wrote in message
>> Malcolm McLean wrote:
>>>
>> Intel recommend using a 32 bit int on the IA64. Therefore Intel
>> consider 32 bits to be a natural size of the architecture. What makes
>> you think you know Intel architectures better than Intel do.
>>
> All you need to know is that the architecture can address 64 bits of
> address space, and can load 64 bit data elements with reasonable
> efficiency. That's not a deep understanding of the architecture.

No, you also need to know what is efficient.

> What Intel lack is a deep understanding of programming issues.

I suspect they have a lot more knowledge about it than your or I. After
all, they also do compilers!

> The
> result of their policy will be that size_t becomes the default integer
> type.

Nope. For many reasons. Starting with all the code that is using int's
for monetary values. Then there is all the SW using int's for
coordinates. Not to forget all the other uses of int.

> Obviously, if everyone provided 64 bit ints, there would no need for a
> campaign for them.

There is no need for a campaign for them.
--
Flash Gordon

"Malcolm McLean" <> writes:
> "Flash Gordon" <> wrote in message
>> Malcolm McLean wrote:
>>>
>> Intel recommend using a 32 bit int on the IA64. Therefore Intel
>> consider 32 bits to be a natural size of the architecture. What
>> makes you think you know Intel architectures better than Intel do.
>>
> All you need to know is that the architecture can address 64 bits of
> address space, and can load 64 bit data elements with reasonable
> efficiency. That's not a deep understanding of the architecture.
>
> What Intel lack is a deep understanding of programming issues. The
> result of their policy will be that size_t becomes the default integer
> type.

Why should there even be a "default" integer type, especially with the
removal of the implicit int rule in C99? Use whatever type is
appropriate for a given context. If you need a 64-bit signed integer,
you can use long long, int_least64_t, int_fast64_t, or int64_t,
depending on your specific needs.

> Obviously, if everyone provided 64 bit ints, there would no need for a
> campaign for them.

If there were a need for such a campaign, there would probably be more
than one person participating in it.

--
Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"