Re: ptr conversions and values

S.Tobias wrote:
> kuyper@xxxxxxxxxx wrote:
....
> > 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.
>
> Well, no:
> void *v = malloc(sizeof(int));
> int *pi = v;
> *pi = 7;
> float *pf = v; // pf points to int object

No, it points at a location which has the right alignment to store a
float, and which could actually contain a float if
sizeof(float)<=sizeof(int). That location currently contains an int,
but pf doesn't point at that int, since it can't be used to retrieve
that int except by converting it into a pointer of a different type.
It's that pointer of a different type which points at the int object.
If it's a pointer to int, it points at the int as an int. If it's a
pointer to unsigned chare, it points to the int as an array of unsigned
char.

I'll grant you that pf and pi point at the same location in memory;
they just don't point at the same complete object (even if both object
types have the same size). At any one time, one of them points at an
object of the pointed-at type, and the other doesn't point at any valid
object.

....
> That was my point. I just haven't found any guarantees that in
> some conversion the location is turned to the _end_ of an object
> (or to the middle, or elsewhere); ...

In the general case, there is indeed no such guarantee.

> ... and the list was not all about
> conversions after all. I tried to give a few reasons why I thought
> the first byte of an object was distinguished by the language.

It is, in many contexts; but not in the sense of actually being pointed
at by pointer that don't have character type.

.

Relevant Pages

  • Re: Insufficient guarantees for null pointers?
    ... will the compiler know what the bounds are after converting that char * ... to an int *, if it could point to either of two arrays which happen to ... compares equal to the original pointer. ...
    (comp.std.c)
  • Re: Typecast clarification
    ... If 'int' is a four-byte type, there's 24 different byte orders theoretically possible, 6 of which would be identified as Little Endian by this code, 5 of them incorrectly. ... A conforming implementation of C could use the same bit that is used by an 'int' object to store a value of '1' as the sign bit when the byte containing that bit is interpreted as a char. ... there are implicit conversions between void* and any other pointer to to object type. ... If the value is currently of a type which has a range which is guaranteed to be a subset of the the range of the target type, safety is automatic - for instance, when converting "signed char" to "int". ...
    (comp.lang.c)
  • Re: Typecast clarification
    ... If 'int' is a four-byte type (which it is on many ... that 'char' and 'int' number the bits in the same order. ... because you cannot dereference a pointer to void. ... safety is automatic - for instance, when converting "signed char" to ...
    (comp.lang.c)
  • Re: int to int* conversion...
    ... int main ... Right, you don't dereference the pointer, but that's not terribly ... after converting it back to int.. ... "A value of integral type or enumeration type can be explicitly ...
    (comp.lang.c)
  • Re: Memory Structure Pointer Problems
    ... typedef struct sta { ... char* name; ... int num_cmpnds; ... A pointer to a struct cmp is almost ...
    (comp.lang.c)