On Sunday, 12 April 2015 at 15:21:26 UTC, Johan Engelen wrote:
Sorry for not being clear.
I should have thought about it more before answering. :)
I understand why the current bsr behaves like it does, but what
I meant is whether that is the desired behavior of bsr:
bsr( byte(-1) ) == 3
On Sun, 12 Apr 2015 15:21:24 +, Johan Engelen wrote:
>>> 2) Is the current sign-extend up to size_t's width really intended
>>> behavior?
>>
>> It's due to integer promotions, so it should only influence bsr (when
>> it is called with a signed type.)
>
> Sorry for not being clear.
> I underst
2) Is the current sign-extend up to size_t's width really
intended behavior?
It's due to integer promotions, so it should only influence bsr
(when it is called with a signed type.)
Sorry for not being clear.
I understand why the current bsr behaves like it does, but what I
meant is whether t
On Sunday, 12 April 2015 at 11:53:41 UTC, Johan Engelen wrote
My questions:
1) Is it OK to put a more general bsf/bsr in druntime or in
Phobos? (if Phobos: in which package to put it?)
IMO I want a std.integer package for such functions.
I started writing one but I have to rewrite it.
I don't
Currently, druntime only supports bsf/bsf, i.e. finding the first
or last bit set, on size_t [1]; bsf(size_t) and bsr(size_t) are
compiler intrinsics.
Because only size_t is supported, it is cumbersome to write
generic code using bsf/bsr. For example, for 64-bit code
bsr(long(...)) will work, b
