|  | Commit message (Collapse) | Author | Age | Files | Lines | 
|---|
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | 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.
llvm-svn: 154082 | 
| | 
| 
| 
| 
| 
| 
| 
| | if the passed in FileSize is inaccurate.
rdar://11034179
llvm-svn: 152662 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | 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)
llvm-svn: 150197 | 
| | 
| 
| 
| 
| 
| | reading files.
llvm-svn: 145061 | 
| | 
| 
| 
| 
| 
| 
| | 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.
llvm-svn: 145059 | 
| | 
| 
| 
| 
| 
| | protected by ifdef either.
llvm-svn: 142623 | 
| | 
| 
| 
| 
| 
| 
| 
| | 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.
llvm-svn: 139873 | 
| | 
| 
| 
| | llvm-svn: 131829 | 
| | 
| 
| 
| 
| 
| | malloc'ed or mmap'ed memory.  This is for performance analysis.
llvm-svn: 130432 | 
| | 
| 
| 
| | llvm-svn: 128098 | 
| | 
| 
| 
| | llvm-svn: 127853 | 
| | 
| 
| 
| 
| 
| | instead of copying.
llvm-svn: 127835 | 
| | 
| 
| 
| | llvm-svn: 127426 | 
| | 
| 
| 
| | llvm-svn: 127417 | 
| | 
| 
| 
| | llvm-svn: 127413 | 
| | 
| 
| 
| 
| 
| | support for creating buffers that cover only a part of a file.
llvm-svn: 127409 | 
| | 
| 
| 
| 
| 
| | MemoryBuffer::getOpenFile to not close the file descriptor.
llvm-svn: 125128 | 
| | 
| 
| 
| | llvm-svn: 122193 | 
| | 
| 
| 
| 
| 
| | via an out parm.
llvm-svn: 121958 | 
| | 
| 
| 
| 
| 
| | error_code &ec. And fix clients.
llvm-svn: 121379 | 
| | 
| 
| 
| | llvm-svn: 120298 | 
| | 
| 
| 
| 
| 
| | file descriptor into a MemoryBuffer (and closes the FD).
llvm-svn: 120065 | 
| | 
| 
| 
| 
| 
| | documented and only used by some clang stuff I just removed.
llvm-svn: 120002 | 
| | 
| 
| 
| | llvm-svn: 106856 | 
| | 
| 
| 
| 
| 
| | needs it.
llvm-svn: 106841 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| | buffer in the same chunk of memory.
2 less mallocs for every uninitialized MemoryBuffer and 1 less malloc for every
MemoryBuffer pointing to a memory range translate into 20% less mallocs on
clang -cc1 -Eonly Cocoa_h.m.
llvm-svn: 106839 | 
| | 
| 
| 
| 
| 
| 
| | instead of a StringRef, avoiding the need to copy the string in the
common case.
llvm-svn: 106754 | 
| | 
| 
| 
| | llvm-svn: 106538 | 
| | 
| 
| 
| | llvm-svn: 104855 | 
| | 
| 
| 
| 
| 
| | a co-committed clang patch.
llvm-svn: 100485 | 
| | 
| 
| 
| | llvm-svn: 100107 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| | - Use a RAII object to close the FD.
- Use sys::StrError instead of thread-unsafe strerror calls.
- Recover gracefully if read returns zero. This works around an issue on
  DragonFlyBSD where /dev/null has an st_size of 136 but we can't read 136 bytes
  from it.
llvm-svn: 100106 | 
| | 
| 
| 
| 
| 
| 
| | pointer. If given, the structure will be set with the stat information from
the file actually read.
llvm-svn: 98575 | 
| | 
| 
| 
| | llvm-svn: 97259 | 
| | 
| 
| 
| | llvm-svn: 92079 | 
| | 
| 
| 
| 
| 
| | instead of returning an ambiguous reason.
llvm-svn: 90275 | 
| | 
| 
| 
| 
| 
| 
| 
| | lame API.
Also, Stringrefify some more MemoryBuffer functions, and add two performance FIXMEs.
llvm-svn: 86630 | 
| | 
| 
| 
| 
| 
| | not reason based on errno if NumRead has a different value.
llvm-svn: 86046 | 
| | 
| 
| 
| 
| 
| | if zero bytes were read.
llvm-svn: 85922 | 
| | 
| 
| 
| 
| 
| 
| | It doesn't matter for piped input, but it's annoying when typing at the 
console.
llvm-svn: 71998 | 
| | 
| 
| 
| 
| 
| | exceptions.
llvm-svn: 64448 | 
| | 
| 
| 
| | llvm-svn: 64444 | 
| | 
| 
| 
| | llvm-svn: 50659 | 
| | 
| 
| 
| | llvm-svn: 50475 | 
| | 
| 
| 
| | llvm-svn: 49055 | 
| | 
| 
| 
| 
| 
| 
| 
| | start of a filename, not a filename+length.  All clients can produce a
null terminated name, and the system api's require null terminated 
strings anyway.
llvm-svn: 49041 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | 1) stop using MappedFile.
2) if profitable use the sys::path::MapInFilePages api to
   read the file.
3) otherwise fallback to read.
When sys::path::MapInFilePages is implemented, this provides
several benefits:
#1: this avoids fragmenting memory for small files.
#2: this avoids extraneous stat calls when the file size is known.
#3: this only keeps the file descriptor open while reading the 
    file, not for the duration of the lifetime of the memory 
    buffer.  This fixes a serious clang FD 'leak' problem.
I believe that this will work on a win32 machine, but I don't have
one to test on.  I'd appreciate it if someone could check.
llvm-svn: 49031 | 
| | 
| 
| 
| 
| 
| | make getBase() return a const-correct pointer.
llvm-svn: 49025 | 
| | 
| 
| 
| 
| 
| 
| | and shared.  This complicates the design, is not used, and probably
doesn't even work.
llvm-svn: 49022 | 
| | 
| 
| 
| | llvm-svn: 45418 |