Re: [boost] [config] RFC PR 82

Subject: Re: [boost] [config] RFC PR 82
From: Domagoj Saric (dsaritz_at_[hidden])
Date: 2015-12-15 18:23:31

On 1.12.2015. 15:18, Agustín K-ballo Bergé wrote:
> IMHO this is short-sighted. Boost.Move is a temporary solution until we
> transition into well-defined semantics, and as such it only has to be
> supported in those now old compilers that do not support real move
> semantics. Your code, on the other hand, would have to be verified and
> supported in every new compiler version that pops up, until the end of
> time.
 >
> Now you might think that your code won't be around long enough for it to
> see compilers improving in this area, given the amount of legacy code
> around relying on it, but it doesn't have to. Analyzers and sanitizers
> are growing stronger by the day, and they are designed to catch exactly
> the kind of bad code that you'd wish to leverage. So even if your code
> "just works" now (and in the future), it will be a disservice to users
> when their sanitized runs terminate because of by-design undefined
> behavior within Boost. The solution is, then, to severe the link to
> broken dependencies.

That's all just circular reasoning (silently assuming that some new form 
of 'bitwise casting', like the 'union trick', already part of the C 
standard, will never be part of the C++ standard).

The "Boost.Move transition into well-defined semantics" at one point had 
to be started by a typical ugly-hack-workaround probing into not so well 
defined semantics (i.e. std::auto_ptr)...

That compilers like GCC, that otherwise adhere very closely to the C++ 
language standard in general and aliasing rules in particular, offer 
explicit, documented, defined ways to work around some difficulties 
concerning the aliasing rules (e.g. union type punning, may_alias 
attribute) speaks volumes...
For example 'standard' GCC and Clang headers for SIMD intrisics use the 
may_alias attribute to implement the vector types and pretty much all 
SIMD extension vendors define intrisics exactly for bitwise casts 
between vector types. Obviously if they think that memcpy isn't the 
hammer for every nail there has to be something to it (if nothing else 
then debug build performance - I really want debug builds of my math 
code to be at least fast enough so that I can test them in real time).

And if compiler vendors have been explicitly offering these 'unholy' 
tools for years you don't expect them to disappear silently overnight?

> All these "opinions" are based of course on the abstract notion of a
> `bitcast` function that intends to exploit undefined behavior to do
> type-punning via unions. If you'd wish to go forward with it, I'd ask
> that you present us with a concrete implementation so we can start a
> technical discussion instead.

Actually yes, since I agreed to move this to Boost.Cast, we can cut this 
short until then...

-- 
C++ >In The Kernel< Now!