The attached file illustrates several errors involving casting of references and pointers, including some which are regressions from 3.08 and earlier.

We're exploring two approaches to moving our code forward into 3.51. My previous mail referred illustrated the blocking issues with switching over entirely to explicit pointers; the regressions here illustrate our blocking issues with attempting to continue with our old approach.

the function named "works" works, and is the correct way to do it.

Is the only complaint that the other (incorrect ways) used to work, and now they don't?

There is no such thing as a void reference in any C I know of.

RefPointerBug1 - may indeed be a bug, in a completely superfluous manner (ie never would be used).

RefPointerBug2 - is a mess, and should be invalid if entered (even if syntactically correct). Actually I would prefer if a tazer like device came out from the PC and shocked the user.

The expectations on the newest versions may not have been set quite right. Those of us with experience knew that in order to become more C like, many of the old kludges had to go away. Since the announcements never mentioned backward compatibility it was never expected by me. Those that have libraries depending on 3.08 technology need to either update them, or stay on 3.08. They are NOT going to work unchanged with 3.51 unless the old kludges are re-introduced (please no).

Yes, the first complaint is the regression. We had code that worked, and now we're stuck with no path forward.

RefPointerBug1: "Would never be used" is beside the point: it's logically valid, and therefore must compile. And with complications of macros etc that hide various details of configurations, it might very well get used.

RefPointerBug2: Sorry, but this is the *classic* way to manipulate addresses / references to get, eg., a C++ compiler to do your bidding.

It's classic alright, but of something else.

Thanks for the thoughtful insight.

Before C++ had reinterpret_cast, this paradigm

*(REINTERPRET_TYPE*)(void*)(&variable)

was the only way to reliably cast a variable (which may be a ref) to a REINTERPRET_TYPE&. In that sense, it is classic.

http://codebetter.com/jeremymiller/2006 ... ode-smell/

might explain it better. It is a sign of poor code, to many, myself included. In that sense, it is classic.