In a recent thread there was a confusion about pointers
in c/cc
Algol 68 has
'int' y;
'ref' 'int' py;

C has
int y;
int *py;

This defines py as something that can be dereferenced to
yield an int. This inside out type of definition leads to
confusion.

This is an example that you can compile with gcc
------------------- pointer.cc ------------
#include <stdio.h>
int main()
{ int y, *py;
py=&y;
printf("%x",py);
} ----------------
Running it reveals the address of y, or at least the 32 least
significant bits.

I couldn't find back the thread, but this is a separate subject
anyway. Confirms the superiority of Forth ;-)

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat purring. - the Wise from Antrim -

albert@spenarnc.xs4all.nl wrote:
------------------- pointer.cc ------------
> #include <stdio.h>
> int main()
> {
> int y, *py;
> py=&y;
> printf("%x",py);
> }
> ----------------
> Running it reveals the address of y, or at least the 32 least
> significant bits.

use %p instead of %x

albert@spenarnc.xs4all.nl writes:
> Running it reveals the address of y, or at least the 32 least
> significant bits.

Being able to find the addresses of memory objects is considered a
feature in C and it's used all the time in idiomatic C. In retrospect,
other languages have usually-good ways to do without that feature, such
as references, access types, etc. I think if you are writing an OS or
standalone embedded program in Ada though, it's not unusual to have some
low level parts of it in assembly language, that reach into the access
types and do stuff with the addresses.

In article <8734st1u9a.fsf@nightsong.com>,
Paul Rubin <no.email@nospam.invalid> wrote:
>albert@spenarnc.xs4all.nl writes:
>> Running it reveals the address of y, or at least the 32 least
>> significant bits.
>
>Being able to find the addresses of memory objects is considered a
>feature in C and it's used all the time in idiomatic C. In retrospect,
>other languages have usually-good ways to do without that feature, such
>as references, access types, etc. I think if you are writing an OS or
>standalone embedded program in Ada though, it's not unusual to have some
>low level parts of it in assembly language, that reach into the access
>types and do stuff with the addresses.

All non-toy languages have side-effects. All i/o are side effects.
It is impossible to do that with addresses (ports or memory) that have
connection to the real world, like actuators that close valves.
Relying on an OS only serves to hide this.

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat purring. - the Wise from Antrim -

albert@spenarnc.xs4all.nl writes:
> All non-toy languages have side-effects. All i/o are side effects.
> It is impossible to do that with addresses (ports or memory) that have
> connection to the real world, like actuators that close valves.
> Relying on an OS only serves to hide this.

I don't see what you're getting at here. It's far preferable to isolate
the unsafe operations to a few places in the program, than to have them
pervading the code base. E.g. you can't really write a garbage
collector without dealing with memory addresses, but if the GC is part
of a Lisp interpreter, the user's Lisp program doesn't have to be able
to see the raw addresses.