POSIX: wchar.h and wctype.h don't need the locale.h but locale_t.h

* missed in hrev56270.
* mentioned on IRC: <dwa> please ask them if wchar.h isn't meant to include locale_t.h instead of locale.h

Change-Id: Ia9b7553480430c2fefb4a3659ad525322152582b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5797
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>

libs/posix: Implemented new locale functions

Implemented the missing POSIX functions in <locale.h>:
newlocale, duplocale, uselocale, and freelocale, and also
provided missing type definitions for <locale.h>.

Implemented missing POSIX locale-based function variants.

Modified LocaleBackend so that it could support thread-local
locales.

Some glibc-like locale-related variables supporting
ctype and printf family of functions have also been updated
to reflect the thread-local variables present in the latest
glibc sources.

As there have been some modifications to global symbols
in libroot, libroot_stubs.c has been regenerated.

Bug: #17168
Change-Id: Ibf296c58c47d42d1d1dfb2ce64042442f2679431
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5351
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>

Fix #7008: Add a64l and l64a from glibc, and add some missing definitions in wchar.h and stdlib.h

Signed-off-by: Jérôme Duval <jerome.duval@gmail.com>

wchar.h & string.h: use _GNU_SOURCE instead of __USE_GNU.

Rename parameters to avoid compile error

* warning: declaration of `signal' shadows global declaration

wchar.h: fix header comment style.

Comment uses C++ style, while it can be compiled in a C-only environment. This
broke the ICU cross compilation (done for ARM).

Updated copyright in headers. No functional change.

Cleanup: correct variable name in mbrtowc() signature.

Switch wchar from glibc to our own implementations.

Adjust mbstate_t to embed the state of the ICU converter.

* 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.

Squash TODO: __STDC_ISO_10646__ is being defined now.

Adjust mbstate_t to what we need.

* we maintain the character count and the ID of the corresponding
ICU converter in mbstate_t

Fix #6969 (hopefully for real this time):
* 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

* reintegrated posix-locale

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37725 a95241bf-73f2-0310-859d-f6bbb57e9c96

Second go at fixing what should have been part of r31927:
* 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

* reverted r37669, as gcc4 enables wchar_t-related template types, but
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

Fix that should have been part of r31927:
* 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

correctly ordered


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34171 a95241bf-73f2-0310-859d-f6bbb57e9c96

added wcsdup to wchar.h


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34169 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Removed superfluous wcstoul() version pointed out by Scott.
* Removed superfluous "int" before wcstol().
* Minor cleanup.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33957 a95241bf-73f2-0310-859d-f6bbb57e9c96

Add missing definition for wcsstr. This was preventing clucene from building with wide chars enabled.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32038 a95241bf-73f2-0310-859d-f6bbb57e9c96

* added missing declarations of all the scanf() variants, as we now provide
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

* synced wchar.h with POSIX and the implementations provided by our libroot
* 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

Removed my Copyright notice, assign future copyright to Haiku Inc, in contribution to ticket #2191

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27068 a95241bf-73f2-0310-859d-f6bbb57e9c96

Patch by Andreas Faerber:
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

Second stab at reorganizing standard/gcc headers. This time it not only
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

Reverted r24406. If it builds, it doesn't always work as well. The
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

* Removed our stddef.h. We don't need it, since gcc comes with one that
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

Added C++ guard. I don't know, why we define the <wctype.h> protos both
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

Should fix the build.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16817 a95241bf-73f2-0310-859d-f6bbb57e9c96

added posix_gnu_string
added more posix definitions


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16813 a95241bf-73f2-0310-859d-f6bbb57e9c96

added some wchar.h definitions


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16803 a95241bf-73f2-0310-859d-f6bbb57e9c96

Moved mbstate to wchar.h
Restored glibc/wcsmbs/wchar.h


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11451 a95241bf-73f2-0310-859d-f6bbb57e9c96

add header protection, and two posix compliant prototypes that are provided by R5 libroot.so


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@5814 a95241bf-73f2-0310-859d-f6bbb57e9c96

a few new headers for compatibility


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@1625 a95241bf-73f2-0310-859d-f6bbb57e9c96

Fix #7008: Add a64l and l64a from glibc, and add some missing definitions in wchar.h and stdlib.h

Signed-off-by: Jérôme Duval <jerome.duval@gmail.com>

wchar.h & string.h: use _GNU_SOURCE instead of __USE_GNU.

Rename parameters to avoid compile error

* warning: declaration of `signal' shadows global declaration

wchar.h: fix header comment style.

Comment uses C++ style, while it can be compiled in a C-only environment. This
broke the ICU cross compilation (done for ARM).

Updated copyright in headers. No functional change.

Cleanup: correct variable name in mbrtowc() signature.

Switch wchar from glibc to our own implementations.

Adjust mbstate_t to embed the state of the ICU converter.

* 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.

Squash TODO: __STDC_ISO_10646__ is being defined now.

Adjust mbstate_t to what we need.

* we maintain the character count and the ID of the corresponding
ICU converter in mbstate_t

Fix #6969 (hopefully for real this time):
* 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

* reintegrated posix-locale

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37725 a95241bf-73f2-0310-859d-f6bbb57e9c96

Second go at fixing what should have been part of r31927:
* 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

* reverted r37669, as gcc4 enables wchar_t-related template types, but
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

Fix that should have been part of r31927:
* 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

correctly ordered


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34171 a95241bf-73f2-0310-859d-f6bbb57e9c96

added wcsdup to wchar.h


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34169 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Removed superfluous wcstoul() version pointed out by Scott.
* Removed superfluous "int" before wcstol().
* Minor cleanup.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33957 a95241bf-73f2-0310-859d-f6bbb57e9c96

Add missing definition for wcsstr. This was preventing clucene from building with wide chars enabled.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32038 a95241bf-73f2-0310-859d-f6bbb57e9c96

* added missing declarations of all the scanf() variants, as we now provide
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

* synced wchar.h with POSIX and the implementations provided by our libroot
* 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

Removed my Copyright notice, assign future copyright to Haiku Inc, in contribution to ticket #2191

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27068 a95241bf-73f2-0310-859d-f6bbb57e9c96

Patch by Andreas Faerber:
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

Second stab at reorganizing standard/gcc headers. This time it not only
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

Reverted r24406. If it builds, it doesn't always work as well. The
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

* Removed our stddef.h. We don't need it, since gcc comes with one that
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

Added C++ guard. I don't know, why we define the <wctype.h> protos both
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

Should fix the build.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16817 a95241bf-73f2-0310-859d-f6bbb57e9c96

added posix_gnu_string
added more posix definitions


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16813 a95241bf-73f2-0310-859d-f6bbb57e9c96

added some wchar.h definitions


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16803 a95241bf-73f2-0310-859d-f6bbb57e9c96

Moved mbstate to wchar.h
Restored glibc/wcsmbs/wchar.h


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11451 a95241bf-73f2-0310-859d-f6bbb57e9c96

add header protection, and two posix compliant prototypes that are provided by R5 libroot.so


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@5814 a95241bf-73f2-0310-859d-f6bbb57e9c96

a few new headers for compatibility


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@1625 a95241bf-73f2-0310-859d-f6bbb57e9c96