gcc 13 is confused by the custom bitset implementation, so use the C++
standard one instead.
However, this results in including the C++ <string> header in kernel
code. This doesn't work for gcc2, because of two problems:
- That header includes a declaration of atomic_add that doesn't match
the one in SupportsDefs.h (which can in some cases replace the function
with a #define for an inline version). Adjust the header to use the
be a problem because it creates a risk of circular inclusions.
Standard C++ headers shouldn't depend on BeAPI ones.
- It also leads to the inclusion of iostream which defined lock and
unlock functions in the global namespace. We don't want these, and they
are not part of the C++ standard, so just remove them.
Ideally we could use std::hash for the GetHashCode implementation, but
that doesn't work because it depends on an helper function that's in
libstdc++, and we can't link that from kernel add-ons.
Change-Id: Iee07280beb4dddf7a9b6160e37f3b816e4de89ae
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6663
Reviewed-by: Niels Sascha Reedijk <niels.reedijk@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
gcc2 was relying on the c99 functions being there, but they are not in
the std namespace.
* Disable the C99 functions and macros in C++ mode
* Redefine them as inline functions in cmath in the std namespace.
Fixes#7396.
and types.h. The idea is to provide a basic architecture/compiler
abstraction by defining types and macros that allow the posix/ and os/
headers to be mostly architecture/compiler agnostic.
* Adjusted the posix/ and os/ headers accordingly.
* <SupportDefs.h>: Introduced B_PRI* and B_SCN* macros similar to the PRI*
and SCN* macros defined in <inttypes.h>, just for the BeOS/Haiku [u]int*
types and some POSIX types (e.g. off_t, dev_t, ino_t) that don't have POSIX
macros. Also the B_PRI* and B_SCN* macros are available unconditionally,
unlike the <inttypes.h> macros, which require __STDC_FORMAT_MACROS to be
defined in C++ mode.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34214 a95241bf-73f2-0310-859d-f6bbb57e9c96
all allocations, instead we now directly request the use of malloc/free in
stl_config.h. This avoids warnings about 'arrays of size 0' when building
any stl-code with -pedantic (like e.g. ICU does).
Alternatively, we could active pthread-type threading support, but since in
some small tests, I have not been able to see any advantage, I've just added
a respective comment.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31609 a95241bf-73f2-0310-859d-f6bbb57e9c96
keeps its own idea about what a wchar_t is and that was still a short.
This of course made the data structure of a streambuf incompatible with the
"lower" half - the glibc part - causing (potentially all sorts of) crashes
when these classes were used.
This should fix the crash of gensyscalls when building haiku natively
on a gcc2-haiku.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31462 a95241bf-73f2-0310-859d-f6bbb57e9c96
of trunk]
Fixed a bug exposed by changes in the locale kit branch:
* the signature of stringbuf::setbuf() wasn't matching the one from streambuf,
which caused the base version to be hidden instead of overridden - leading
to crashes during cleanup of stringstream objects
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31262 a95241bf-73f2-0310-859d-f6bbb57e9c96
zooey agreed when discussing this (and we hope this don't break anything)
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11660 a95241bf-73f2-0310-859d-f6bbb57e9c96
- this differs slightly from the one that lives in buildtools/gcc as it
has been "ported" to the newer libio that haiku uses as part of its own
libroot
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@9906 a95241bf-73f2-0310-859d-f6bbb57e9c96
