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
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.
-- AgustÃn K-ballo BergÃ©.- http://talesofcpp.fusionfenix.com