Subject: Re: 64bit issues
To: None <port-alpha@netbsd.org>
From: Peter Seebach <seebs@plethora.net>
List: port-alpha
Date: 12/18/1999 21:31:23
In message <Pine.LNX.3.96.991218213555.32620A-100000@guild.net>, Lord Isildur w
rites:
>Not in a language like C!!!! this kind of stuff has no place in C!
Sure it does! C isn't supposed to be restricted to low-level code only.
>Languages that provide high-level insulation from the real syste, sure,
>they can do this kindo f thing to their heart's content, because there, a
>'pointer' is merely a meansof referencing some strictly defined and
>controlled data element[s]. In C, a pointer means a memory address.
No. In C, a "pointer" and an "address" are synonymous - but they mean
"a way of identifying another object".
Real C implementations exist where differing pointer types have
representations that aren't even the same size as *each other*.
(The famous one is one of the old 64-bit implementations where char
pointers have to have extra fixup data to let them byte-address a machine
addressed by 64-bit chunks.)
>It
>is blasphemous to try to bind to that any sort of imposition on what to
>expect at the other end of that pointer, or to try to tell one how to
>interpret the data in that space!!!
No, it's a useful feature.
Here's the idea: The language does *NOT* promise that you can do certain
things, such as alias one kind of pointer through another.
The best way to detect shaky code is to run it on an implementation which
checks all pointer accesses at runtime.
In real use, you wouldn't *always* get failures, but you'd get them
*sometimes*, because you would *sometimes* end up running invalid code.
>If you like this sort of restriction,
>then dont use C, there are plenty of high-level languages that support
>plenty of this [personally repulsive] stuff! then, though, you may as well
>not use the term 'pointer' for it!
"pointer" is a very good word for "a thing which points".
My favorite example of a C implementation consists of me, a few pencils, and a
stack of post-it notes of various colors. With accompanying documentation, I
can be a functional C implementation. :)
C is an abstract language, because once you start talking about "the real
machine", you risk limiting yourself to machines very similar to the one
you know.
-s