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
