Re: [hash2] Comments

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2024-12-07 00:29:13

On 12/7/24 03:23, Ivan Matek wrote:
> 
> 
> On Sat, Dec 7, 2024 at 1:08 AM Andrey Semashev via Boost
> <boost_at_[hidden] <mailto:boost_at_[hidden]>> wrote:
> 
>     On 12/7/24 01:42, Ivan Matek wrote:
>     >
>     >
>     > On Fri, Dec 6, 2024 at 10:36 PM Andrey Semashev via Boost
>     > <boost_at_[hidden] <mailto:boost_at_[hidden]>
>     <mailto:boost_at_[hidden] <mailto:boost_at_[hidden]>>> wrote:
> 
> 
>     As to the usage with the forced move, I don't think the added complexity
>     is justified. If the goal is to make sure the hash value doesn't change
>     upon successive calls to result() (to use the existing nomenclature)
> 
> 
> Goal was to "encourage" users in 2 ways to call result() only once.
> First way is that move signals that value is "tainted", second is that
> clang-tidy can detect double moves sometimes. 
> Â 
> 
>     Â But I don't see the benefit in introducing UB (potentially, to be
>     caught by sanitizers - *if* one runs
>     one) upon subsequent calls to result().
> 
> 
> If you are referring to multiple calls to
> get_digest(std::move(h));
> There is no UB. Move is just a cast, we do not nuke the member when we
> return it's result(), and clang-tidychecks are static(not runtime).

It may be UB if the hasher's result() has an rvalue-qualified overload
that moves parts of its internal representation out in the returned hash
value.