It was only used to implement ExecuteAndWait and ExecuteNoWait. Expose just
those two functions and make Execute and Wait implementations details.
llvm-svn: 183864
The sys::fs::is_directory() check is unnecessary because, if the filename is
a directory, the function will fail anyway with the same error code returned.
Remove the check to avoid an unnecessary stat call.
Someone needs to review on windows and see if the check is necessary there or not.
llvm-svn: 176386
/dev/stdin as an input when stdin is connected to a tty, for example.
No test, because it's difficult to write a reasonably portable test
for this. /dev/stdin isn't a character device when stdin is redirected
from a file or connected to a pipe.
llvm-svn: 175542
Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module
include to be the nearest plausible thing I could find. If you own or
care about any of these source files, I encourage you to take some time
and check that these edits were sensible. I can't have broken anything
(I strictly added headers, and reordered them, never removed), but they
may not be the headers you'd really like to identify as containing the
API being implemented.
Many forward declarations and missing includes were added to a header
files to allow them to parse cleanly when included first. The main
module rule does in fact have its merits. =]
llvm-svn: 169131
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
llvm-svn: 160075
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
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
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
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
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
- 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
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
Rafael Espindola