🚀 go-pugleaf

In article <2173@sdrc.COM> scjones@thor.sdrc.com (Larry Jones) writes:
>In article <1992Oct27.073329.6679@netcom.com>, rfg@netcom.com (Ronald F. Guilmette) writes:
>< [rearranged somewhat]
>< I'm having a hard time understanding just what the standard says (let
>< alone what it means) when it comes to implicit conversions of one
>< pointer type to another.
>< 
>< Now section 3.2.2.3 seems pretty clear, but I know that there are other
>< bits of relevant stuff hiding elsewhere in the standard (but I'm not
>< sure where anymore).  I'm pretty sure that the phrase "a qualified or
>< unqualified version of void" is lurking in there somewhere... and it
>< may relate to this "conversions" issue... but where is it that I saw
>< that?
>
>3.2 only specifies the results of a conversion.  The conversions it
>describes are NOT applied automatically, the description of each
>operator in 3.3 says which conversions to apply.

OK.  I think I get it now.

If I understand you correctly, you are saying that all of section 3.2 (and
its subsections) describe (in general terms) *possible* implicit conversions,
but the *actual* conversions which may be applied in any given context will
depend upon the operator being used (which, in the case of my question, was
the `=' operator).

While I must admit that this sounds entirely reasonable, I still have some
problems with this explanation.

Specifically, consider:

		const char *ccp;
		const void *cvp;

			cvp = ccp;

Now if I understood you, you are saying that this should be allowed because
the description of the operator `=' says (in effect) that it is OK to
assign a value of type pointer-to-T1 (where T1 is some qualified or
unqualified object type) to an lvalue which has type pointer-to-T2, where
`T2' is a (possibly qualified) void type which has *at least* the same
qualifiers as type T1 has.  Yes?

That all seems reasonable, but *only* as long as we read *only* 3.3.16.1
and *ignore* the verbage in 3.2.2.3 (which does *not* give *any* permission
for a value of type pointer-to-qualified-object to be implicitly converted
to a pointer-to-qualified-void.

Clearly, the problem is that the verbage in 3.2.2.3 SHOULD HAVE SAID that
there exists a (potential) implicit conversion from pointer-to-T1 to
pointer-to-T2 where T1 is a (possibly qualified) object type and where
T2 is a void type which has AT LEAST the qualifiers that T1 has.  (But
3.2.2.3 failed to say this... an ommission which, in my opinion, is a
bug in the standard.)  As it is, 3.2.2.3 *only* says that a pointer-to-T1
may be converted (implicitly, in some circumstances, depending upon the
operator) to a value of type pointer-to-PLAIN-void.  That's a problem.

Any disagreement?

(I also have another problem with Larry Jones's explanation, but it goes
way off onto another tangent, so I'll save it for a separate message.)


// Ron ("Loose Cannon") Guilmette
// uucp: ...uunet!lupine!segfault!rfg
// New new motto:  Quality control is a state of mind.
//   misc.forsale.computers ad, circa 2007:
//       Used Cray wrist watch for sale; 25 bucks or best offer.
-- 

// Ron ("Loose Cannon") Guilmette
// uucp: ...uunet!lupine!segfault!rfg
// New new motto:  Quality control is a state of mind.
//   misc.forsale.computers ad, circa 2007:
//       Used Cray wrist watch for sale; 25 bucks or best offer.