Re: [boost] [config] RFC PR 82

Subject: Re: [boost] [config] RFC PR 82
From: Agustín K-ballo Bergé (kaballo86_at_[hidden])
Date: 2015-12-01 09:18:12

On 12/1/2015 3:16 AM, Domagoj Šarić wrote:
> On Thu, 26 Nov 2015 07:43:24 +0530, Agustín K-ballo Bergé
> <kaballo86_at_[hidden]> wrote:
>> As for the original topic, I am certain that having the proposed macro
>> would be a mistake. Don't try to fool a language/compiler smarter than
>> you, or you will end up getting what you asked for (UB) sooner or
>> later. If you have types whose values are comprised by just a set of
>> bits, and you'd wish to operate on said value representation, then do
>> so by using the tools for operating on the value representation of
>> such trivial types. Type punning via unions is not that tool.
>
> IMNHO that's just generic paranoia and refusing to even look outside the
> box...we'd still be using C++98 with this kind of thinking (e.g.
> Boost.Move is 'fooling' the pre-C++11 compiler just like templates weren't
> originally designed as a tool for TMP or CRTP)...
> Not to mention that various compilers explicitly prescribe ways to be
> 'fooled' (union type punning for GCC&compatibles, MSVC does not use the
> aliasing rules at all - Windows wouldn't boot if it did, etc...)

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.

But what tops it all, what makes this decision a plain and simple 
mistake, is that this "just works" because implementations map this kind 
of undefined behavior into specific well-defined behavior. So it's just 
undefined behavior for the sake of "pretty syntax" (a subjective thing 
at best). Why then wouldn't you just simply write that well-defined code 
that these implementations are translating to?

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.

Regards,
-- 
Agustín K-ballo Bergé.-
http://talesofcpp.fusionfenix.com