[llvm-bugs] [Bug 37552] New: No warning on truncation of integers when using make_unique/shared

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=37552

            Bug ID: 37552
           Summary: No warning on truncation of integers when using
                    make_unique/shared
           Product: libc++
           Version: 6.0
          Hardware: PC
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: All Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: helge at penne.no
                CC: llvm-bugs at lists.llvm.org, mclow.lists at gmail.com

The following code fails to correctly produce a warning (with -Wall and
-Wextra) when the int is converted to uint8_t inside make_unique and the value
is modified from 0x100 to 0:

#include <cstdint>
#include <memory>

struct Foo {
    uint8_t m_v;
    Foo(uint8_t v) : m_v{v} {}
};

void f() {
    auto a = std::make_unique<Foo>(0x100); // No warning with any compiler
options
    auto b = std::unique_ptr<Foo>(new Foo(0x100)); // Warning with default
options
}

Same for make_shared and possibly also allocate_shared.  This is probably due
to warnings being disabled in the library.

Security critical code needs warnings on all integer conversions that can
result in truncation or altered values.  This bug means that the use of
make_unique/make_shared is unsafe, and should not be permitted at all in
security critical products that compile with clang.  That makes this a somewhat
critical bug.

Similar problems exist with the "emplace" family of functions, but I see those
as less critical (but I might be wrong).  Developers are probably more likely
to use the old functions than emplace to insert integers into collections,
while make_unique/shared is used quite frequently.

This problem illustrates the danger of disabling warnings in header libraries
that makes use of templates.  When the template "generates" code on behalf of
the programmer and warnings are off, then important warnings may fail to be
issued.  This is likely to get worse as the standard libraries get more
advanced over time.  The policy of disabling all warnings in libraries is
inherently dangerous and should ideally be reviewed...

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20180522/048f5e4d/attachment-0001.html>