Re: ptr conversions and values
- From: "S.Tobias" <siXtY@xxxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: 13 Oct 2005 13:10:42 GMT
[order of quotes slightly rearranged]
kuyper@xxxxxxxxxx wrote:
> S.Tobias wrote:
>> kuyper@xxxxxxxxxx wrote:
> ...
>> > ... Since a
>> > representation is a mapping, two representations can't be equivalent
>> > unless the sets that they map to contain equivalent members. An integer
>> > value can't be equivalent to a pointer value, so representations of
>> > integers can't be equivalent to representations of pointers.
[snip]
>> Making values of different types equivalent means nothing more
>> that joining them in pairs.
>
> Joining them in pairs is called mapping, not equivalence.
>
Whatever. My choice of words was poor. I called them "equivalent"
as I could not call them "equal"; later I found "corresponding"
was a better word.
> For two values to be equivalent requires, essentially, that they have
> the same meaning. Two arithmetic values have the same meaning if
> they're mathematically equal. Two pointer values are equivalent if they
> point at the same object. Two character values are equivalent if they
> represent the same character. Two aggregate values are equivalent if
> their corresponding elements are equivalent. A pointer value can't have
> the same meaning as an integer value, so they can't be equivalent.
What I cannot comprehend is how you can accept that a complex type
and a corresponding array, or an imaginary and a corresponding real,
can have the "same meaning", and a pointer and an integer can't.
>> ... To say that two types have the same
>> representation means that paired values share the same
>> bit-patterns (I don't go into any more details here, that's my
>> basic understanding).
>
> True; but only if you pair together equivalent values. A memory
> location can't meaningfully be said to be equivalent to an integer.
>
>> How you make those pairs is pretty arbitrary.
>
> Not true: if you're pairing together inequivalent values, the fact that
> you chose to pair them together doesn't make the representations of
> those values equivalent.
>
Of course most such pairings would not be sensible. In my
generalization I was trying to develop a widest possible
interpretation while still keeping things consistent, and see how far
it could go (if there were two interpretations, there could be N).
The problem is which values are to be considered equivalent, and
that _may_ be arbitrary to some extent.
[snip]
> A mapping from bit patterns to memory locations is fundamentally
> different from a mapping from bit patterns to integer values.
How is this "fundamental difference" different from mapping to
complex types and to corresponding arrays? I don't do anything
substantially different that the Standard does: I attach additional
meaning to an integer and treat it as a pointer that points at the
location of an i'th byte in a char array that occupies the whole
memory. I couple an integer and a pointer when they "point" at the
same location. How is it different from what the Standard does:
it attaches a meaning of a complex number to an array of two reals,
and joins it with a complex type that expresses the same value.
[snip]
>I think you're asserting that there's a unique
> mapping from integers to memory locations that should be used to define
> what it means when you say that the representation of an integer type
> is equivalent to the representation of a pointer type.
I don't say it's unique, but that this one is sensible.
>The C standard
> provides no support for that assertion. Furthermore, the standard
> doesn't give us any reason to care whether they have the same
> representation.
No it doesn't, and I never claimed that it did or should. I meant
this as an example how I think talking about the same representation
of unrelated types could be useful.
>
> Can you provide an example of a case where we would care?
>
In case of no convenient pointer-integer conversion (on my imagined
implementation) this knowledge could be used to analyze the pointer
value and infer its alignment and other properties.
>> In my reply to recent Wojtek's post, I gave my reasons why I thought
>> that equivalence between different types need not necessarily
>> involve conversions. ...
>
> The true connection is through values, not conversions.
I assume you think of integers here. Thanks, you're the first
person to acknowledge this openly.
>However, it's
> not a coincidence that there's a connection; the C standard generally
> defines conversions between values of two different types in precisely
> those cases where the values are meaningfully equivalent.
>
> Pointer conversions tend to be an exception; for instance, in many
> cases it allows you convert a pointer to one type into a pointer to a
> different type, but there's no meaningful sense in which the values of
> the two different pointer types can be considered equivalent. On most
> real implementations, the original pointer and the pointer produced by
> the conversion would point at the same location in memory, so the
> locations they point to are equivalent, even if the objects they point
> to cannot be called equivalent. However, when the types are unrelated
> to each other the standard doesn't require that the converted pointer
> point at the same memory location as the original; it only requires
> that, upon conversion back to the original type, the resulting pointer
> value points at the same function/object as the original.
I agree with all that mostly. Only I still can't understand
why "pointers are equivalent when they convert into each other"
should be better than "when they point at the same location".
I don't see it explicitly in the Standard. Everything else you
write I can accept, but it is a hand-waving for me, not a proof.
> While the existence of a conversion connecting two values of different
> types doesn't prove them equivalent, the absence of a conversion proves
> them inequivalent. That's not because the standard says so, but simply
> because the standard does define the conversion whenever the values are
> equivalent (and that's not a coincidence).
_Complex and array don't support this claim. _Imaginary and real
equivalence is not based on conversion. (I understand that whenever
there's a conversion, there's usually some connection between the
types; but here we're talking about equivalence (correspondence)
for the purposes of "same representation".)
> ...
>> >> > For complex numbers, the real and imaginary components of the number
>> >> > are themselves real numbers, and therefore each have the same target
>> >> > set as the corresponding real type, and it's only those components that
>> >> > are required to have the same representation as the corresponding real
>> >> > type.
>> >> >
>> >> No, it's not only the components. There can't be padding between
>> >> or outside the components. The real component must lie at the
>> >> beginning of the complex object, and imaginary right after it,
>> >> and complex type object must be continuous (ie. no holes).
[snip]
>a complex value must have the same representation as an array
> of two elements of the corresponding real types, and therefore cannot
> have padding bytes between them. But how does that justify saying "No"
> to my statement that the components of the complex type are the only
> parts that are required to have the same representation as the
> corresponding real type?
[snip]
>The compenents of an object of type
> "complex T" are required to have the same representation as T itself;
> no other aspect of "complex T" is required to have that representation.
In the first place my "No" meant that the requirement of same
representation was stronger than one just for the components.
Secondly, I object to your way of reasoning. You cannot talk about
components of complex types, because you don't know it until you
make the said requirement (it's similar to using the results of a
theorem in order to prove that theorem). Mathematically complex
values may be defined as pairs of real values, but this does not
necessarily need to be reflected in the representation of complex
types; they can be split into components *because* they have the same
representation as a corresponding array (which does have components).
--
Stan Tobias
mailx `echo siXtY@xxxxxxxxxxxxxxxxxxxxxxxxxx | sed s/[[:upper:]]//g`
.
- Follow-Ups:
- Re: ptr conversions and values
- From: kuyper
- Re: ptr conversions and values
- From: Wojtek Lerch
- Re: ptr conversions and values
- Prev by Date: Re: Argument of free() should be const void*
- Next by Date: Re: Argument of free() should be const void*
- Previous by thread: Argument of free() should be const void*
- Next by thread: Re: ptr conversions and values
- Index(es):
Relevant Pages
|
Loading
