diff options
| author | Kristóf Umann <dkszelethus@gmail.com> | 2022-10-05 18:11:12 +0200 |
|---|---|---|
| committer | Kristóf Umann <dkszelethus@gmail.com> | 2022-10-26 17:22:12 +0200 |
| commit | a504ddc8bf9d5c406ea88b84b8495d7aae200d4c (patch) | |
| tree | b0795ad2291998ce1bcb1078248cbceef3569de5 /lldb/packages/Python/lldbsuite/test/lldbgdbclient.py | |
| parent | 3aec0211187b98c4a4e48872df20e86a775e7a8a (diff) | |
| download | llvm-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/lldbgdbclient.py')
0 files changed, 0 insertions, 0 deletions