which contains slashes is inconsistent with the meaning of PATH on
Unix-type platforms, and pretty surprising.
If the user has given a specific path to execute and we can't
execute it, we should fail and say why. (Apparently the new
posix_spawn code doesn't always say why, but that's a separate
issue.)
llvm-svn: 117596
Original commit message:
On "Unix", if Program::FindProgramByName is given a name containing
slashes, just go with it, regardless of whether it looks like it will
be executable. This follows the behavior of sh(1) more closely.
It's better when behaviour is consistent between platforms. This change also
makes FindExecutable() behave as expected on unix-likes (before this commit, it
used to always succeed).
llvm-svn: 117582
catch(...) is used in Win32/Signals.inc for catching Win32 structured
exceptions, but according to [1], this is wrong.
We can't simply change try/catch to __try/__finally, since this syntax is not
supported by MinGW. We can use __try/__finally on MSVC and __try1/__except1
macros on MinGW [2], but I think that that solution obfuscates the code too
much.
The use of try/catch(...) in Signals.inc makes it impossible to link
MinGW-compiled libSystem with llvm-gcc compiled executables. I propose that we
just remove try/catch(...) from Signals.inc, since the meaning of the code won't
change.
[1] http://members.cox.net/doug_web/eh.htm
[2] http://article.gmane.org/gmane.comp.compilers.llvm.cvs/81315
llvm-svn: 117442
getMagicNumber was treating the _binary_ data it read in as a
null terminated string. This resulted in the std::string
calculating the length, and causing an assert in other code that
assumed that the length it passed was the same as the length of
the string it would get back.
llvm-svn: 112586
According to the Microsoft documentation here:
http://msdn.microsoft.com/en-us/library/ms724284%28VS.85%29.aspx
this cast used in lib/System/Win32/Path.inc:
__int64 ft = *reinterpret_cast<__int64*>(&fi.ftLastWriteTime);
should not be done. The documentation says: "Do not cast a pointer to a
FILETIME structure to either a ULARGE_INTEGER* or __int64* value because
it can cause alignment faults on 64-bit Windows."
llvm-svn: 112376
of the current thread. This has the unfortunate effect that assert() and abort()
will end up bypassing our crash recovery attempts. We work around this for
anything in the same linkage unit by just defining our own versions of the
assert handler and abort.
llvm-svn: 111583
Dan Gohman