Re: ptr conversions and values
- From: kuyper@xxxxxxxxxx
- Date: 3 Sep 2005 09:25:12 -0700
S.Tobias wrote:
> Wojtek Lerch <Wojtek_L@xxxxxxxx> wrote:
....
> For me pointers differ in ability to point to things (alignment),
> but once a pointer points to one thing, it may point to many things.
> For an example, suppose an implementation on which `float' and `int'
> have different size and alignment. But once you have an address that is
> suitably aligned for both types (eg. malloc) you can store an integer in
> there, but keep references to it in a pointer to float throughout the
> whole program, and access the value through this pointer appropriately
> converted and dereferenced. IOW a pointer doesn't know what object type
> it is really pointing to.
An address doesn't know what object type it is really pointing at.
However, a C pointer isn't just a memory address; it always has a
specific type it's pointing at, (possibly an incomplete one, and in the
case of void, it might be an incomplete type that can't be completed).
As such it only directly points at an object of it's pointed-at type.
It must be converted to a different pointer value before it can be used
to access an object of that new values pointed-at type. In many cases,
the standard guarantees that the new value will refer to the same
memory location, but they could have different representations for that
location. Also, the standard guarantees that the new value will refer
to the same location in far fewer cases than most programmers expect.
....
> Even in lack of definition for (char*) conversions[*] (some would still
> have to be defined), the first byte would still be more natural (more
> important) than others, I think. I'm thinking of unions (members aligned
> on the first byte); an array expression is converted to a pointer to
> its first element; a struct and its first member have the same address
> (ie. no padding, but there may be unspecified padding at the other end);
> pointers to incomplete array types must indicate the start of the array
> rather than the end (or any other part), because the same pointer
> might point to different arrays in a union at the same time - both
> small and very big; similar argument for the generic pointer type
> (void*) and other incomplete pointer types; two pointers point to
> the same object if both objects start on the same byte.
> I think the core of the C language is biased towards the "first" whatever.
You've just listed cases where the standard guarantees something about
the location pointed at by a pointer when it's converted to a different
type. There's lots of other cases where it makes no such guarantee.
> >If I take a pointer that points to a
> > two-byte structure and reinterpret its bits as a pointer to a two-megabyte
> > structure, does the resulting pointer point to an object?
>
> Yes, if the object they point to is well-aligned for both types.
Where does it say that? If the two types have no special relationship
to each other, there's no guarantee where the converted pointer points;
only a guarantee that converting it back to the original type will
produce a pointer value equivalent to the original.
....
> In 6.2.5#15 it says `char' shall be defined to have "the same range,
> representation, and *behaviour*" as either `un/signed char'. So there
> was a way to well describe what I was talking about - similar words
> could have been used for `void*' and `char*' types.
My copy of the standard is at home, and I'm not, so I can't give you
the citation, but it does say pretty much the same thing about the
connection between void* and char*.
.
- Follow-Ups:
- Re: ptr conversions and values
- From: S.Tobias
- Re: ptr conversions and values
- From: Wojtek Lerch
- Re: ptr conversions and values
- References:
- Re: ptr conversions and values
- From: S.Tobias
- Re: ptr conversions and values
- Prev by Date: Re: ptr conversions and values
- Next by Date: Secure C library
- Previous by thread: Re: ptr conversions and values
- Next by thread: Re: ptr conversions and values
- Index(es):
Relevant Pages
|