Re: ptr conversions and values
- From: "S.Tobias" <siXtY@xxxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: 28 Nov 2005 16:46:49 GMT
Wojtek Lerch <Wojtek_L@xxxxxxxx> wrote:
> "S.Tobias" <siXtY@xxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
> news:3skov0Fol4fhU1@xxxxxxxxxxxxxxxxx
> >> S.Tobias wrote:
> >> ...
> >> > 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.
> > WL> They don't have the same meaning. That's why the standard explicitly
> > WL> specifies what pairs of values have the same representation:
> > [snip Std quotes]
> >
> > A complex number is not an array, either.
>
> Exactly; that's why it's insufficient to just say that they have the same
> representation, without providing an explanation of what pairs of values are
> meant to have the same representation. Just like it would be insufficient
> to say it about pointers and integers.
>
Yes. So I have given an explanation how to connect integers to pointers
(on the particular implementation), without which "same representation"
wouldn't have any meaning.
> > What I try to discover is the reason for outright rejection of the
> > wording. Before Annex G was added, would you object to the wording that
> > on some implementation (compliant with future Standard) "_Complex types
> > have the same representation as an array of ...", just because it wasn't
> > in the Standard yet?
>
> You mean before 6.2.5p13?
Er, yes.
>I would object if the wording didn't contain the
> bits of the "..." that explain how the parts of the complex number
> correspond to the elements of the array. Just like I would object if you
> said that on implementation X, pointers have the same representation as
> unsigned int. But I have nothing against saying that on implementation X,
> pointers have the same representation as unsigned int, where the numerical
> value of the unsigned is the machine address of the first byte of the
> pointed-to object. Provided, of course, that machine addresses on
> implementation X are simple integer numbers. This wouldn't work in an
> environment where a machine address behaves like a pair of integers, or a
> bunch of bitfields.
Then we're in agreement here, I think.
The Standard doesn't explain whether two pointer values correspond to
each other when they point to the same location or when they convert
into each other. No-one has yet provided a definitive proof that it
must be either (or any other) way. I hope you can agree with me it's a
fair conclusion to this discussion to say that the Standard is ambiguous
(or incomplete) at this point.
> >> ...
> >> > 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".
> >
> > WL> Because it better covers the case where the location has correct
> > alignment
> > WL> for one type but not the other.
> >
> > Reinterpretation doesn't seem to have any more or any less "issues" wrt
> > alignment as conversion does.
[ I'm sorry, I can't recall now what exactly I had in mind here (it's also
possible I was wrong). If I can remember it, I'll return here later. ]
> Huh? What kind of issues reinterpretation has depends on how you define it.
> We're disagreeing about how it should be defined, aren't we?
>
> If you define it in terms of conversions, like I'd like to, then yes, it
> won't have any more or any less issues than conversion does.
>
> If you define it in terms of "location", it still depends on *how*. If you
> say that for any two *valid* pointer values that point to different struct
> types but point to the same "location", the sets of bit patterns that
> represent them are the same, then I'm OK with that. But if you say that for
> any *one* valid pointer to a struct type, you can reinterpret its
> representation as a pointer to a different struct type, and the result is
> *guaranteed* to be a valid pointer that points to the same "location", then
> I see that as a problem, because you'd be introducing the concept of a
> "valid" pointer value that points to a location that doesn't have the
> correct alignment. This kind of half-valid pointers would be a wart in the
> language that was supposed to be eliminated by making the conversion
> undefined. It would be a mistake to define the reinterpretation in a way
> that would allow people to produce values that can't be produced in more
> appropriate ways, such as by conversions.
>
The Standard allows valid pointer values, that don't point to valid
locations (null ptr, malloc(0), so I don't consider it a big problem.
Secondly, the requirement for the same representation always goes with
that for the same alignment. If two types are required to have the same
alignment, it's sort of an invitation to access the location with lvalues
of both types. I'd find it odd if the part about the same representation
wasn't such an invitation for bit patterns as well.
To check if a pattern valid in one type is also valid in another with
the same representation, is practically impossible in my model (in yours
you could examine if conversion for that value is valid). That's where
I mainly see the value of guaranteeing the validity for both types, and
it falls within my idea of what interchangeability should be (ie. that
there should be no need to check).
> > WL>And it doesn't introduce situations where
> > WL> two values are guaranteed to be equivalent in some sense, but the only
> > way
> > WL> to produce one from the other is not by a conversion but by
> > reinterpreting
> > WL> the representation. It would be a bad idea to encourage
> > reinterpreting of
> > WL> representations as a safer substitute for conversions.
> >
> > Either I misunderstand you, or you may have confused something.
>
> Or both. ;)
>
> > The equivalent value (in the model for pointers I've been advocating)
> > is produced by converting to `void*' and then to the other type (then
> > both pointers point to the same location). Reinterpretation appears
> > in both our models and is the purpose of the "same representation"
> > (values from reinterpreted bit-patterns are to be the same or
> > equivalent - whatever it means).
>
> But if the other type has stricter alignment requirements and the original
> value doesn't meet them, the conversion from void* is undefined. What value
> does the reinterpretation produce then, in you model?
>
Argh, now I see what you mean, and you've got me! I simply shouldn't have
said anything how to produce the equivalent value, it's enough to say that
the equivalent pointer is that which points to the same location. I don't
find it especially disturbing that there's no formula how to obtain it, I
don't see any special need for this.
--
Stan Tobias
mailx `echo siXtY@xxxxxxxxxxxxxxxxxxxxxxxxxx | sed s/[[:upper:]]//g`
.
- Prev by Date: Re: Intent of the (u)int_fastN_t types
- Next by Date: Re: Varying representations of ptrdiff_t; legal?
- Previous by thread: Re: ptr conversions and values
- Next by thread: Intent of the (u)int_fastN_t types
- Index(es):
Relevant Pages
|
