* instead of unification, we now keep both our and glibc's fields
separate in order to allow for both our code and glibc's to use
such a struct at the same time (independently)
* _IO_USER_BUF was being used to indicate a user-owned buffer without
taking into account that there are two of those: one for the normal
and another one for the wide version of a stream. Backport
_IO_FLAGS2_USER_WBUF from current glibc version to fix that.
* Rename init_sse to init_fpu and handle FPU setup.
* Stop trying to set up FPU before VM init.
We tried to set up the FPU before VM init, then
set it up again after VM init with SSE extensions,
this caused SSE and MMX applications to crash.
* Be more logical in FPU setup by detecting CPU flag prior
to enabling FPU. (it's unlikely Haiku will run on
a processor without a fpu... but lets be consistant)
* SSE2 gcc code now runs (faster even) without GPF
* tqh confirms his previously crashing mmx code now works
* The non-SSE FPU enable after VM init needs tested!
* add Wcscoll() and Wcsxfrm() ICU locale backend
* provide implementations of wcscoll() and wcsxfrm() that are using
the respective methods of the locale backend
Mostly done because olta want less dependency on glibc.
It should also make porting a tiny bit simpler.
Testresults, mean values on Haiku from libMicro:
* with glibc: strlen_10: 0.03859S, strlen_1k: 1.67075S.
* with strlen.cpp: strlen_10: 0.03854S, strlen_1k: 1.66938S.
So at least on my machine it's possible to beat glibc ;)
* Use TimeZone::SHORT specifier instead of SHORT_COMMONLY_USED, since
the former yields more appropriate (textual) values. Strangely enough,
it used to be the other way around, which is why we didn't used SHORT
in the past.
* Glibc declares and uses its own version of mbstate_t, which is
incompatibly with our own. Mix our own fields into glibc's
mbstate_t, such that the two structs are compatible.
* 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.
* the reference to MB_CUR_MAX requires stdlib.h
* if an conversion error occurs, the returned src pointer must point to
the character that triggered the error
* src was sometimes accessed incorrectly (needs double dereference)
* the source pointers may only be adjusted in case there is the
destination pointer is not NULL
* add MultibyteStringToWchar() to ICU locale backend
* implement mbsrtowcs() and mbsnrtowcs() on top of
MultibyteStringToWchar()
* drop respective glibc files
When forking a team, copy on write areas (and therefore caches) are
created for all the areas in the parent team, but they were always
created as swappable. If the parent team had some B_FULL_LOCK areas,
which aren't swappable, the wrong type of cache would be created which
lead to them not being mergeable later on (causing a panic).
Comments about a possibly cleaner way to figure out the cache type
would be welcome.
* Define a MEMALIGN macro that is either just defined to malloc() or
to the actual memalign() depending on where KMessage is used. We only
use memalign() inside the kernel and libroot.
* Add a comment to the macro explaining that this allows the use of
special heap implementations that might return unaligned buffers for
debugging purposes.
The change in hrev43405 wasn't correct, as it put the reference
object definition after the one of the corresponding locker, causing
the reference to be released before the unlock would happen.
Finally fixes#8187. Thanks Ingo for pointing that out.
While this isn't really correct, it works for the use case it is
intended and doesn't open the can of worms we get when trying to do
memalign() across platforms (due to build tools use of KMessage).