[all-commits] [llvm/llvm-project] 06e047: [libcxx][NFC] Tidy up calculation of __nbuf in num...

[DanielMcIntosh-IBM via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 06e047227d71b2c1c477e280172abed0f1eed2c8
      https://github.com/llvm/llvm-project/commit/06e047227d71b2c1c477e280172abed0f1eed2c8
  Author: Daniel McIntosh <Daniel.McIntosh at ibm.com>
  Date:   2021-06-02 (Wed, 02 Jun 2021)

  Changed paths:
    M libcxx/include/locale

  Log Message:
  -----------
  [libcxx][NFC] Tidy up calculation of __nbuf in num_put::do_put, and add comments

In 07ef8e679621 and 3ed9f6ebdeeb, `__nbuf` started to diverge from the amount
of space that was actually needed for the buffer. For 32-bit longs for example,
we allocate a buffer that is one larger than needed. Moreover, it is no longer
clear exactly where the extra +1 or +2 comes from - they're just numbers pulled
from thin air. This PR cleans up how `__nbuf` is calculated, and adds comments
to further clarify where each part comes from.

Specifically, it corrects the underestimation of the max size buffer needed
that the above two commits had to compensate for. The root cause looks to be
the use of signed type parameters to numeric_limits<>::digits. Since digits
only counts non-sign bits, the calculation was acting as though (for a signed
64-bit type) the longest value we would print was 2^63 in octal. However,
printing in octal treats values as unsigned, so it is actually 2^64. Thus,
using unsigned types and changing the final +2 to a +1 is probably a better
option.

Reviewed By: #libc, ldionne, Mordante

Differential Revision: https://reviews.llvm.org/D103339