«

* Pete Becker, on 29.07.2010 21:35:
> On 2010-07-29 15:28:41 -0400, Jonathan Lee said:
>
>> On Jul 29, 3:17 pm, Pete Becker <p...@versatilecoding.com> wrote:
>>> On 2010-07-29 14:22:16 -0400, Jonathan Lee said:
>>>> Hence my qualification: "assuming argument was a float* originally".
>>>
>>>> (Not looking at the original message, but I think that was a
>>>> reasonable assumption.)
>>>
>>> I guess I'm reacting to "guarantees this particular cast is correct".
>>> If argument was a float* in the first place, a C-style cast and a
>>> static_cast do exactly the same thing. And if argument was not a float*
>>> they also do the same thing. So I don't see what the "guarantee" here
>>> is.
>>
>> Ah, I see. When I mentioned the guarantee originally, it was in the
>> context of static_cast vs reinterpret_cast, i.e., that static_cast
>> says this conversion to void* and back is fine, whereas I don't
>> believe reinterpret_cast does.
>>
>> The general point I was trying to make was to favour the other
>> casts over reinterpret_cast, if there was any choice. The bit about
>> C-style casts hadn't crept into the discussion at that time.
>>
>
> Okay, so I muddled things with my automatic reaction that when someone
> talks about guarantees they're contrasting with a C-style cast. You're
> absolutely right, of course: the result of a round-trip conversion
> through a reinterpert_cast<void*> is unspecified.

A reinterpret_cast roundtrip conversion through void* is not unspecified, but is
guaranteed to yield the original pointer, by §5.2.10/7 (and §3.9.2/4).


Cheers & hth.,

- Alf

--
blog at <url: http://alfps.wordpress.com>

* Pete Becker, on 30.07.2010 01:22:
> On 2010-07-29 18:17:55 -0400, Alf P. Steinbach /Usenet said:
>
>> * Pete Becker, on 29.07.2010 21:35:
>>> On 2010-07-29 15:28:41 -0400, Jonathan Lee said:
>>>
>>>> On Jul 29, 3:17 pm, Pete Becker <p...@versatilecoding.com> wrote:
>>>>> On 2010-07-29 14:22:16 -0400, Jonathan Lee said:
>>>>>> Hence my qualification: "assuming argument was a float* originally".
>>>>>
>>>>>> (Not looking at the original message, but I think that was a
>>>>>> reasonable assumption.)
>>>>>
>>>>> I guess I'm reacting to "guarantees this particular cast is correct".
>>>>> If argument was a float* in the first place, a C-style cast and a
>>>>> static_cast do exactly the same thing. And if argument was not a
>>>>> float*
>>>>> they also do the same thing. So I don't see what the "guarantee" here
>>>>> is.
>>>>
>>>> Ah, I see. When I mentioned the guarantee originally, it was in the
>>>> context of static_cast vs reinterpret_cast, i.e., that static_cast
>>>> says this conversion to void* and back is fine, whereas I don't
>>>> believe reinterpret_cast does.
>>>>
>>>> The general point I was trying to make was to favour the other
>>>> casts over reinterpret_cast, if there was any choice. The bit about
>>>> C-style casts hadn't crept into the discussion at that time.
>>>>
>>>
>>> Okay, so I muddled things with my automatic reaction that when someone
>>> talks about guarantees they're contrasting with a C-style cast. You're
>>> absolutely right, of course: the result of a round-trip conversion
>>> through a reinterpert_cast<void*> is unspecified.
>>
>> A reinterpret_cast roundtrip conversion through void* is not
>> unspecified, but is guaranteed to yield the original pointer, by
>> §5.2.10/7 (and §3.9.2/4).
>>
>
> 5.2.10/7 (second sentence):
>
> Except that converting an rvalue of type “pointer to T1� to the type
> “pointer to T2�
> (where T1 and T2 are object types and where the alignment requirements
> of T2
> are no stricter than those of T1) and back to its original type yields
> the original
> pointer value, the result of such a pointer conversion is unspecified.
>
> void is not an object type, so void* does not meet the requirements in
> parentheses.

Right, I didn't see that.

But there is already a known defect that sentence, namely direct contradiction
between its "Except that ..., the result ... is unspecified", and §9.2/17, "A
pointer to a POD-struct object, suitably converted using reinterpret_cast,
points to its initial member (or if that member is a bit-field, then to the unit
in which it resides) and vice versa", which is at least one more case where the
result /is/ specified.

And that sentence would, with literal interpretation, force round-trip
conversion guarantee for all object pointer types (of suitable alignment) as
intermediary, but not for void*, where the compiler would be free to sort of
mess up things by always producing the nullpointer value, say.

As I see it that can't have been the intention, since it is absurd and of no
practical value.

And the existing defect in the same sentence means that it does suffer from
known lack of rigorousness, hence more likely that the absurdity is a defect,
and not the result of moronic intention, yes?


> The result is unspecified.

Yeah, now you point it out I agree that it's formally unspecified -- *but*,
that's IMO a defect. Anyway, it's absurd. The standard isn't about providing
means and ways of the compiler messing up things in malicious ways.


> Note that 3.9.2/4 does not say that void* is a pointer to object type;
> rather, it says that void* can be used to point to an object of unknown
> type.

Yes, I understood that.


Cheers & hth., & thanks,

- Alf

--
blog at <url: http://alfps.wordpress.com>

On 29.07.2010 20:31, Jonathan Lee wrote:
> Furthermore, this is probably "no code". I can't see, for
> example, void* and float* having different representations on
> x86 machines. I've heard that some CPUs have different
> pointers for floats than chars, which might mean void* has
> a different representation (since it is required to represent
> both). In such a case, code would be generated.
>
thanks, i've known that C++ guarantee that all pointers to any objects
are of the same size but didn't take into account that it can be the
largest possible pointer on target platform.

by the way, yesterday i turned over the pages of Satters' book
(exceptional C++) and found his note that С++ type casting operators
were chosen to be long enough with the purpose to make their use more
complicated (and force programmers to doubt their use necessity).

--
Ruslan Mullakhmetov

On Jul 30, 1:51 am, "Alf P. Steinbach /Usenet" <alf.p.steinbach
+use...@gmail.com> wrote:
> * Pete Becker, on 30.07.2010 01:22:

[...]
> >> A reinterpret_cast roundtrip conversion through void* is not
> >> unspecified, but is guaranteed to yield the original pointer, by
> >> §5.2.10/7 (and §3.9.2/4).

> > 5.2.10/7 (second sentence):

> > Except that converting an rvalue of type “pointer to T1” to
> > the type “pointer to T2” (where T1 and T2 are object types
> > and where the alignment requirements of T2 are no stricter
> > than those of T1) and back to its original type yields the
> > original pointer value, the result of such a pointer
> > conversion is unspecified.

> > void is not an object type, so void* does not meet the requirements in
> > parentheses.

> Right, I didn't see that.

> But there is already a known defect that sentence, namely
> direct contradiction between its "Except that ..., the result
> ... is unspecified", and §9.2/17, "A pointer to a POD-struct
> object, suitably converted using reinterpret_cast, points to
> its initial member (or if that member is a bit-field, then to
> the unit in which it resides) and vice versa", which is at
> least one more case where the result /is/ specified.

> And that sentence would, with literal interpretation, force
> round-trip conversion guarantee for all object pointer types
> (of suitable alignment) as intermediary,

I don't see where you read that. The first element of
a POD-struct object must have have the same address as the
complete object, which means that it must be suitably aligned
for the complete object. Consider the case of a word addressed
machine, where char* contains extra information specifying the
byte in the word. The address of a POD-struct type (or int, or
anything but a char type) doesn't contain this information.
Converting a char* to some other pointer type, then back, looses
this information, so the resulting char* would point to the
first char in the word, and not the char it originally pointed
to. If the first element in the POD-struct is a char, however,
it is the first char in the first word of the POD-struct, so the
results still satisfy the requirements.

> but not for void*,
> where the compiler would be free to sort of mess up things by
> always producing the nullpointer value, say.

Except that void* is guaranteed to have the same size and
representation as char*, so any guarantees for char* sort of
apply to void* as well. (I think. The guarantee concerning the
same size and representation were present in C; I presume that
C++ makes the same guarantee.)

--
James Kanze

* James Kanze, on 30.07.2010 12:18:
> On Jul 30, 1:51 am, "Alf P. Steinbach /Usenet"<alf.p.steinbach
> +use...@gmail.com> wrote:
>> * Pete Becker, on 30.07.2010 01:22:
>
> [...]
>>>> A reinterpret_cast roundtrip conversion through void* is not
>>>> unspecified, but is guaranteed to yield the original pointer, by
>>>> §5.2.10/7 (and §3.9.2/4).
>
>>> 5.2.10/7 (second sentence):
>
>>> Except that converting an rvalue of type “pointer to T1” to
>>> the type “pointer to T2” (where T1 and T2 are object types
>>> and where the alignment requirements of T2 are no stricter
>>> than those of T1) and back to its original type yields the
>>> original pointer value, the result of such a pointer
>>> conversion is unspecified.
>
>>> void is not an object type, so void* does not meet the requirements in
>>> parentheses.
>
>> Right, I didn't see that.
>
>> But there is already a known defect that sentence, namely
>> direct contradiction between its "Except that ..., the result
>> ... is unspecified", and §9.2/17, "A pointer to a POD-struct
>> object, suitably converted using reinterpret_cast, points to
>> its initial member (or if that member is a bit-field, then to
>> the unit in which it resides) and vice versa", which is at
>> least one more case where the result /is/ specified.
>
>> And that sentence would, with literal interpretation, force
>> round-trip conversion guarantee for all object pointer types
>> (of suitable alignment) as intermediary,
>
> I don't see where you read that.

5.2.10/7 (second sentence), it's what it specifies.


> The first element of
> a POD-struct object must have have the same address as the
> complete object, which means that it must be suitably aligned
> for the complete object. Consider the case of a word addressed
> machine, where char* contains extra information specifying the
> byte in the word. The address of a POD-struct type (or int, or
> anything but a char type) doesn't contain this information.
> Converting a char* to some other pointer type, then back, looses
> this information, so the resulting char* would point to the
> first char in the word, and not the char it originally pointed
> to.

Yeah, that's what my "of suitable alignment" is about.

It seems that you violently agree with me.


> If the first element in the POD-struct is a char, however,
> it is the first char in the first word of the POD-struct, so the
> results still satisfy the requirements.

>> but not for void*,
>> where the compiler would be free to sort of mess up things by
>> always producing the nullpointer value, say.

Regarding this statement, I was a bit hasty: the compiler is only free to mess
up things if the original object is not a POD struct or first member of such. It
seems a very peculiar license to mess up, very arbitrary; but I think is just
defect.


> Except that void* is guaranteed to have the same size and
> representation as char*, so any guarantees for char* sort of
> apply to void* as well. (I think. The guarantee concerning the
> same size and representation were present in C; I presume that
> C++ makes the same guarantee.)

Yeah. As mentioned, this seems to be an additional defect in /the same
sentence/, that is, 5.2.10/7 (second sentence).


Cheers,

- Alf

--
blog at <url: http://alfps.wordpress.com>