* make room in mbstate_t for containing an ICU-converter's state
(well, in fact the whole converter object)
* adjust libroot's locale add-on to clone converters into a given
mbstate_t directly
* adjust ICUThreadLocalStorageValue to contain the converter pointer
instead of a converter-ID (if the converter is related to an
mbstate_t, it points into the mbstate_t).
* adjust users of converters to directly use converter pointers
instead of ICUConverterRef
* drop now unused ICUConverterManager and ICUConverterRef
* update gcc4 optional package
This brings our multibyte implementation into a fully working state,
both non-ascii and non-8-bit characters can now be handled normally
in the Terminal, i.e. this finally fixes#6276.
N.B.: Since the size of mbstate_t has changed, everything (including
the compiler!) needs to be rebuilt.
* move all the isw... functions from wchar.h to wctype.h (just following version 7
of the POSIX base specs)
* remove all declarations from wchar.h that are in wctype.h, too
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41832 a95241bf-73f2-0310-859d-f6bbb57e9c96
* uncommented fwscanf() in wchar.h to make it available
* imported wcsftime() from FreeBSD-8 (which just wraps strftime()), so that we
not only declare it, but provide an implementation, too
As a result, the next build of gcc4 should be able to detect full support for wchar_t and in turn activate wchar_t-based template types (like std::wstring).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37720 a95241bf-73f2-0310-859d-f6bbb57e9c96
then fails to build them because of wcsftime() missing
Needs more investigation ...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37674 a95241bf-73f2-0310-859d-f6bbb57e9c96
* uncommented fwscanf() in wchar.h to make it available
As a result, the next build of gcc4 should be able to detect full support for wchar_t and in turn activate wchar_t-based template types (like std::wstring).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37669 a95241bf-73f2-0310-859d-f6bbb57e9c96
those, too. Among other things, this should facilitate making use of wstring
with gcc4.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31927 a95241bf-73f2-0310-859d-f6bbb57e9c96
* added WCHAR_MIN and WCHAR_MAX - already as 32-bit values, since that's
what wchar_t is going to become, soon (and those values could not have
been used before, since they were missing)
* this is still work-in-progress though, I need to run more tests to find
out which of these functions are actually working, too
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31182 a95241bf-73f2-0310-859d-f6bbb57e9c96
Replaced single-line comments by multi-line comments for ANSI C
compliance.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25433 a95241bf-73f2-0310-859d-f6bbb57e9c96
builds on Linux with gcc 2 and 4, but the images do even run. :-) Not
tested on BeOS.
* Removed stddef.h and stdarg.h. They are provided by the compiler.
* Adjusted size_t.h, wchar_t.h, and wchar.h accordingly.
* Made stdio.h avoid gcc 2.95.3's fixincludes hack stdio_va_list
* Added gcc 2.95.3 headers to the repository. They are used instead of
the headers of the gcc 2.95.3's we use to compile Haiku with. Should
avoid build problems with the BeOS native compiler.
For sake of personal recreation you can rebuild the cross gcc 2.95.3,
but the only thing that changed is its header directory
(lib/gcc-lib/.../include), which isn't used anymore. Replacing it with
headers/build/gcc-2.95.3 should have the same effect as rebuilding, BTW.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24413 a95241bf-73f2-0310-859d-f6bbb57e9c96
change resulted in "version mismatch between boot loader and kernel". So
apparently the size of some type changed unintentionally.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24408 a95241bf-73f2-0310-859d-f6bbb57e9c96
under Haiku overrides ours anyway.
* Adjusted size_t.h, wchar_t.h, wchar.h accordingly. This should fix the
annoying "ssize_t redefined" warnings when compiling under Haiku.
* When building Haiku the gcc headers come first in the include
search path now, as it should be. The respective TODO suggested that
this might break the build depending on compiler version and host
platform. I've tested with Linux gcc 2 and gcc 4, which work fine.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24406 a95241bf-73f2-0310-859d-f6bbb57e9c96
there and in <wchar.h>. Any reason for not removing them in <wctype.h>? Or
maybe even nicer reverse the inclusion direction, i.e. remove the
duplicate protos in <wchar.h> and include <wctype.h> instead.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20317 a95241bf-73f2-0310-859d-f6bbb57e9c96
Puck Meerburg