file buffer is null-terminated.
If the file is smaller than we thought, mmap will not allow dereferencing
past the pages that are enough to cover the actual file size,
even though we asked for a larger address range.
rdar://11612916
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@160075 91177308-0d34-0410-b5e6-96231b3b80d8
the caller requested a null-terminated one.
When mapping the file there could be a racing issue that resulted in the file being larger
than the FileSize passed by the caller. We already have an assertion
for this in MemoryBuffer::init() but have a runtime guarantee that
the buffer will be null-terminated, so do a copy that adds a null-terminator.
Protects against crash of rdar://11161822.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@154082 91177308-0d34-0410-b5e6-96231b3b80d8
Unify default construction of error_code uses on this idiom so that users don't
feel compelled to make static globals for naming convenience. (unfortunately I
couldn't make the original ctor private as some APIs don't return their result,
instead using an out parameter (that makes sense to default construct) - which
is a bit of a pity. I did, however, find/fix some cases of unnecessary default
construction of error_code before I hit the unfixable cases)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@150197 91177308-0d34-0410-b5e6-96231b3b80d8
This was put in because in a certain version of DragonFlyBSD stat(2) lied about the
size of some files. This was fixed a long time ago so we can remove the workaround.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145059 91177308-0d34-0410-b5e6-96231b3b80d8
gold plugin is built with Large File Support (sizeof(off_t) == 64 on i686)
and the rest of LLVM is built w/o Large File Support
(sizeof(off_t) == 32 on i686) which corrupts the stack.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@139873 91177308-0d34-0410-b5e6-96231b3b80d8