aboutsummaryrefslogtreecommitdiff
path: root/lldb/packages/Python/lldbsuite/test
diff options
context:
space:
mode:
authorKristóf Umann <dkszelethus@gmail.com>2022-10-05 18:11:12 +0200
committerKristóf Umann <dkszelethus@gmail.com>2022-10-26 17:22:12 +0200
commita504ddc8bf9d5c406ea88b84b8495d7aae200d4c (patch)
treeb0795ad2291998ce1bcb1078248cbceef3569de5 /lldb/packages/Python/lldbsuite/test
parent3aec0211187b98c4a4e48872df20e86a775e7a8a (diff)
downloadllvm-a504ddc8bf9d5c406ea88b84b8495d7aae200d4c.zip
llvm-a504ddc8bf9d5c406ea88b84b8495d7aae200d4c.tar.gz
llvm-a504ddc8bf9d5c406ea88b84b8495d7aae200d4c.tar.bz2
[analyzer] Initialize regions returned by CXXNew to undefined
Discourse mail: https://discourse.llvm.org/t/analyzer-why-do-we-suck-at-modeling-c-dynamic-memory/65667 malloc() returns a piece of uninitialized dynamic memory. We were (almost) always able to model this behaviour. Its C++ counterpart, operator new is a lot more complex, because it allows for initialization, the most complicated of which is the usage of constructors. We gradually became better in modeling constructors, but for some reason, most likely for reasons lost in history, we never actually modeled the case when the memory returned by operator new was just simply uninitialized. This patch (attempts) to fix this tiny little error. Differential Revision: https://reviews.llvm.org/D135375
Diffstat (limited to 'lldb/packages/Python/lldbsuite/test')
0 files changed, 0 insertions, 0 deletions