When it is amoral... (Re: When is a cast not a cast?)

Wayne A. Throop throopw at bert.dg.com
Mon May 8 12:22:13 AEST 1989


> bph at buengc.BU.EDU (Blair P. Houghton)
> Thanks to all who pushed me upright.  

I think either your seat or your tray table is not yet in the
full upright position, because what you say here:

> I think I've got it [..that is, the misunderstanding about pointer 
> arithmetic..] identified, and I hope someone else benefits from
> my story.  In Jim Kingdon's emailed reply to my original posting, he
> mentioned that I should be wary of scaling in pointer arithmetic.  I
> wrote back:
> 	I know all about the automatic scaling of an integer in
> 	pointer arithmetic.
>       [... and ...]
> 	Now I know much, much better.  A pointer isn't really a
> 	data type at all.  
> [... and ...]
> The way pointers work implies that they don't refer at all to
> anything physical, even to memory locations.

This is wrong.  Very wrong.  First off, the integer is not scaled
in pointer/integer arithmetic.  The pointer is.  Second, pointers
are data types every bit as much as floating point, or integers, or
characters are.  Third, pointers work as if they are references to
any of the types of objects expressable in C (though not all instances
of those objects can be refered to by a pointer value).

The pointer is scaled so that details of particular implementation of
pointer on any machine can be made portable.  The details are hidden by
the compiler, so that machine independant pointer manipulations can be
done.  This is a major innovation in C, and generally (as low level
features go) a Good Thing.

Pointers are data types, in that they are objects which contain 
information just as any other C type does.  As with, say, floating
point types, C remains very cagy about the the exact structure of
pointer data expressed in bits.

And finally pointers have well-defined operations which can be performed
against them, in particular indirection and arithmetic, and well-defined
meanings for the values they can take on.  So I'd say they have a very
good definition of what they "work as if".

> It doesn't change the fact that I'd like to be able to add and subtract
> pointers regardless of what trouble I _might_ get into.  Considering the
> general level of danger incurred by programming in something so potentially
> obfuscatory as C, it's a small barrier to remove.  

So why try to guild the lilly?  This barrier HAS been removed, in that
when pointers and integers are mixed, very reasonable, machine independant
semantics are attached to the process.

The point is, Blair expects an object defined as one type to behave both
as if it were a pointer and an offset at the same time.  This is NOT sensible.

--
If it could be demonstrated that any complex organ existed which coult not
possibly have been formed by numerous, successive, slight modifications,
my theory would absolutely break down.
                              --- Charles Darwin
--
Wayne Throop      <the-known-world>!mcnc!rti!xyzzy!throopw



More information about the Comp.lang.c mailing list