Re: [boost] [outcome] success-or-failure objects

Subject: Re: [boost] [outcome] success-or-failure objects
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2018-01-25 08:32:45

>   1. No checking.  This is performance optimised and leads to UB.  (In
> Ye Olde Outcome, it would have returned a garbage bit pattern that could
> cause all sorts of weird logic, though probably not any far-reaching
> harm due to the way error_code itself works.  In Outcome v2 it's most
> likely going to just return a default-initialised one, which is entirely
> harmless.)

Not to nitpick, but as
https://ned14.github.io/outcome/tutorial/default-actions/happens1/#fn:1
describes, calling .error() when there is no error there results in
*hard* UB. As in, the compiler doesn't generate code to handle the
situation where there is no error, no branches, no stack handling, nothing.

The consequence of that *might* be to proceed as if there is no error,
but sometimes it is not. The Tutorial gives an example of where it
segfaults. You can't really say, depends on what the optimiser generates
for some given situation.

Now, in terms of storage, yes we do always place default initialised E
in there. That's for the C compatibility. But we don't place a default
initialised T there, that can be random bits, so .value() where there is
no value can yield the same random input as you mentioned Outcome v1 had.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/