aboutsummaryrefslogtreecommitdiff
path: root/lldb/source/Commands/CommandObjectMemory.cpp
diff options
context:
space:
mode:
authorGeorge Burgess IV <george.burgess.iv@gmail.com>2015-10-16 01:49:01 +0000
committerGeorge Burgess IV <george.burgess.iv@gmail.com>2015-10-16 01:49:01 +0000
commita51c4077c553c8703832e56ba763428334af8150 (patch)
treee29ca4feada7bfa4fc0a294638f304b3f3c74903 /lldb/source/Commands/CommandObjectMemory.cpp
parent59e847f997a4494c695c89068c4db34fb36de3ab (diff)
downloadllvm-a51c4077c553c8703832e56ba763428334af8150.zip
llvm-a51c4077c553c8703832e56ba763428334af8150.tar.gz
llvm-a51c4077c553c8703832e56ba763428334af8150.tar.bz2
Make __builtin_object_size more conservative
r246877 made __builtin_object_size substantially more aggressive with unknown bases if Type=1 or Type=3, which causes issues when we encounter code like this: struct Foo { int a; char str[1]; }; const char str[] = "Hello, World!"; struct Foo *f = (struct Foo *)malloc(sizeof(*f) + strlen(str)); strcpy(&f->str, str); __builtin_object_size(&f->str, 1) would hand back 1, which is technically correct given the type of Foo, but the type of Foo lies to us about how many bytes are available in this case. This patch adds support for this "writing off the end" idiom -- we now answer conservatively when we're given the address of the very last member in a struct. Differential Revision: http://reviews.llvm.org/D12169 llvm-svn: 250488
Diffstat (limited to 'lldb/source/Commands/CommandObjectMemory.cpp')
0 files changed, 0 insertions, 0 deletions