Unfortunately there are some marked "public" that also use it,
so we can't just move the remainder to an internal file and then
drop libio.h from public consumption.
Delete all the unused portions of the public libio.h while at it.
Adjust the two legacy stdc++ headers that still included it;
it seems they didn't themselves depend on any of the definitions it
contained. However, streambuf.h actually did, so put that definition in
libio.h so that it's always present.
(The stdc++ implementation will get the 'real' _G_config.h from
libroot glibc.)
It's set in _G_config.h, but this file doesn't include that,
so in many cases the "unlocked" function was called instead.
(Most of the stdc++ .cc files did have it set, though.)
It's needed by GCC2 stdc++, but we shouldn't be including it
for all consumers of <stdio.h>, which we were. Drop it,
and adjust all the things that were relying on <stdio_pre.h>'s
definition of __PRINTFLIKE to use the _PRINTFLIKE defined
in BeBuild.h instead.
Hopefully should not cause any breakage; the libroot
implementation of __freading depended on this, but
I didn't see anything else which did.
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 <[email protected]>
Tested-by: Commit checker robot <[email protected]>
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
Kacper Kasper