Some compiler flags and/or compilers will set this instead. There are
undoubtedly others but I know this fixes my problem.
The flag that I'm currently seeing alter this is `-std=c++0x`.
Signed-off-by: Christy Norman <christy@linux.vnet.ibm.com>
On some platforms we got a warning about 'info' not being used because the #if _XOPEN_SOURCE >= 700 || _POSIX_C_SOURCE >= 200809L was not true. Can't remember which platform right now but this patch addressed it.
GCC shows warnings (like:
warning: 'virtual std::streamsize backward::cfile_streambuf::xsputn(const char_type*, std::streamsize)' can be marked override [-Wsuggest-override]
In the cfile_streambuf class. This patch #defines override to be nothingness in C++98 and adds the override keyword to the functions with the warnings.
* functional mac port
* combine common parts of Linux and Darwin implementations
* add unwind support for apple
* insure BACKWARD_HAS_BACKTRACE_SYMBOL is set for BACKWARD_SYSTEM_DARWIN
* fix indentation
* use pthread_self and pthread_main_np
If an executable is run by e.g. being on the PATH (anything that results in argv[0] not being a valid
path to the executable), problems ensue when backward-cpp tries to print a stack trace.
dladdr returns argv[0] in dli_fname for symbols contained in the main executable, which is not a valid
path if the executable was found by a search of the PATH environment variable. Then, load_object_with_bfd
is called on that non-existent filename and fails.
The implemented solution is to detect `dladdr` returning `argv[0]` and replace it with the executable's
path, read from the /proc/self/exe symlink.
In our code, we need to take certain cleanup actions
after receiving a SIGSEGV. This makes it difficult to
integrate with backward, as our custom sighandler is overriden.
A simple solution is to have backward-cpp expose the
core sighandling logic as a public function, which
we can simply call from within our code. This is not
currently possible since sig_handler is private, and
additionally raises the signal again at the end.
This pull request makes the above possible. The alternative
is to copy handleSignal into our own code, which is just ugly.
*Read the pc as specified for aarch64 processors.
*Disable division by zero tests, since aarch64 does not trap these and
therefore does not generate SIGFPEs there.
*All other tests succeed.
for ip==0, we sometimes calculate ip-=1.
ip is unsigned, so this is an underflow.
This is not strictly an UB, but more pedantic sanitizers
do catch this and report as possible error.
So why not instead just explicitly set value 0xffff...
(result of 0-1) and avoid this warnings.
This is a breaking change.
The printer now offers a color_mode setting: automatic, always, never.
When given a FILE* stream on linux, the automatic mode will retrieve
file descriptor behind it and call isatty().
Operator names are not supported by MSVC out of the box. Using them
breaks code that needs to build with MSVC and/or (thus) uses
"-fno-operator-names". As a header-only library should pursue maximal
portability, this commit replaces the single usage of operator names
with the more portable operator syntax.
When the stack trace is used directly (and not by a signal),
one may want to hide some of the first stack items because
they will always be the same calls.
On ArchLinux at least the bfd.h header errors out early if
PACKAGE or PACKAGE_VERSION have not been set. This patch
makes backward.hpp compile on this platform for me.
This change is needed for compatibility to Qt applications.
Qt defines a macro "signals" that expands to nothing and is used by
Qt's meta object compiler (which is kind of a C++ pre-processor) to
add signal-slot feature (http://doc.qt.io/qt-5/signalsandslots.html).
This will cause compilation of backward.hpp to fail, when used from a
Qt application, because the variable "signals" will be expanded to ""
by the cpp pre processor.
