Re: Questioning the overflow check in jemalloc

[Joerg Sonnenberger <joerg%bec.de@localhost>]

On Thu, Sep 07, 2017 at 03:56:15PM +0200, Pierre Pronchery wrote:
> In the first case SIZE_T_MAX is shifted left by 16 bits and in the second
> case 32, as intended. But then why is there a cast to unsigned long long at
> all? The left operand of that binary AND (&) is a size_t anyway, and will
> not have any bits set past that size, since it's been binary OR'd.

It is overcomplicated and inherited. A better way would likely be:
  const size_t low_bits = ((size_t)1 << (sizeof(size_t) * CHAR_BITS / 2)) - 1;

  if (((num | size) & ~low_bits) && num_size / size != num)
    ....

> As a side note, wouldn't it be more correct to bsr (Bit Scan Reverse on x86)
> both operands, add them, and compare them with sizeof(size_t) << 3? That is,
> on platforms with an equivalent instruction available of course. (Answering
> to myself: it seems to have portability and performance impact)

Even if it is available, BSR/FFS is not faster than a mask-and-compare.
Keep in mind that the mask expression is a constant.

That said, if the compiler supports it, using the overflow-reporting
multiplication builtin would certainly be a simpler idea.

Joerg