On Mon, Feb 15, 2021 at 04:37:15PM +0100, Thomas Klausner wrote:
> Hi!
>
> Thanks for the man pages.
>
> There is none for uselocale(3), which is heavily referenced from
> these, nor do I find a prototype in /usr/include...
> so how does one use these? :)
We don't support uselocale. You use
Hi!
Thanks for the man pages.
There is none for uselocale(3), which is heavily referenced from
these, nor do I find a prototype in /usr/include...
so how does one use these? :)
Thomas
On Mon, Feb 15, 2021 at 09:35:04AM -0500, Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
On Mon, Apr 22, 2013 at 01:45:52AM +, YAMAMOTO Takashi wrote:
On Thu, Apr 18, 2013 at 06:58:42AM +, YAMAMOTO Takashi wrote:
On Tue, Apr 16, 2013 at 11:34:52PM +, YAMAMOTO Takashi wrote:
On Tue, Apr 16, 2013 at 11:39:50PM +0900, Takehiko NOZAKI wrote:
so that the struct
On Thu, Apr 18, 2013 at 06:58:42AM +, YAMAMOTO Takashi wrote:
On Tue, Apr 16, 2013 at 11:34:52PM +, YAMAMOTO Takashi wrote:
On Tue, Apr 16, 2013 at 11:39:50PM +0900, Takehiko NOZAKI wrote:
so that the struct _locale __C_locale in libc is much more wasteful.
I should add
On Tue, Apr 16, 2013 at 11:34:52PM +, YAMAMOTO Takashi wrote:
On Tue, Apr 16, 2013 at 11:39:50PM +0900, Takehiko NOZAKI wrote:
so that the struct _locale __C_locale in libc is much more wasteful.
I should add that it is an internal detail and the way the composed C
locale is stored
On Thu, Apr 18, 2013 at 06:58:42AM +, YAMAMOTO Takashi wrote:
On Tue, Apr 16, 2013 at 11:34:52PM +, YAMAMOTO Takashi wrote:
On Tue, Apr 16, 2013 at 11:39:50PM +0900, Takehiko NOZAKI wrote:
so that the struct _locale __C_locale in libc is much more wasteful.
I should add that
On 2013-04-16 00:55, YAMAMOTO Takashi wrote:
On Mon, Apr 15, 2013 at 11:40:57PM +0900, Takehiko NOZAKI wrote:
POSIX2008 spec say, *_l func with invalid locale handle may EINVAL.
NULL or (locale_t)0 is invalid locale handle.
Note that POSIX Issue 7 TC1 was recently published [1], and there are
On Tue, Apr 16, 2013 at 11:34:52PM +, YAMAMOTO Takashi wrote:
On Tue, Apr 16, 2013 at 11:39:50PM +0900, Takehiko NOZAKI wrote:
so that the struct _locale __C_locale in libc is much more wasteful.
I should add that it is an internal detail and the way the composed C
locale is stored
On Tue, Apr 16, 2013 at 04:55:01AM +, YAMAMOTO Takashi wrote:
hi,
On Mon, Apr 15, 2013 at 11:40:57PM +0900, Takehiko NOZAKI wrote:
POSIX2008 spec say, *_l func with invalid locale handle may EINVAL.
NULL or (locale_t)0 is invalid locale handle.
why are you think fallback to C
On Tue, Apr 16, 2013 at 11:39:50PM +0900, Takehiko NOZAKI wrote:
before implementing such non-portable *broken* stuff.
At the very least it is a conforming extension.
...which means keeping a copy around in various libraries etc.
It is possible, but wastes memory.
most of application in
On Tue, Apr 16, 2013 at 11:39:50PM +0900, Takehiko NOZAKI wrote:
That's what Apple and FreeBSD provide and which is actually quite
useful.
useful? don't say that.
I have heard same word from who spreads broken iconv(3) usage,
(such as non-portable //TRANSLIT features that annoying
On Tue, Apr 16, 2013 at 11:39:50PM +0900, Takehiko NOZAKI wrote:
so that the struct _locale __C_locale in libc is much more wasteful.
I should add that it is an internal detail and the way the composed C
locale is stored can and likely will change later. So the way it is
essentially a copy
I can' t understand why this change is needed.
POSIX2008 spec say, *_l func with invalid locale handle may EINVAL.
NULL or (locale_t)0 is invalid locale handle.
why are you think fallback to C locale?
http://pubs.opengroup.org/onlinepubs/9699919799/functions/isalpha.html
On Mon, Apr 15, 2013 at 11:40:57PM +0900, Takehiko NOZAKI wrote:
POSIX2008 spec say, *_l func with invalid locale handle may EINVAL.
NULL or (locale_t)0 is invalid locale handle.
why are you think fallback to C locale?
That's what Apple and FreeBSD provide and which is actually quite
useful.
hi,
On Mon, Apr 15, 2013 at 11:40:57PM +0900, Takehiko NOZAKI wrote:
POSIX2008 spec say, *_l func with invalid locale handle may EINVAL.
NULL or (locale_t)0 is invalid locale handle.
why are you think fallback to C locale?
That's what Apple and FreeBSD provide and which is actually quite
I was just wondering why this change was made? It seems to be a backwards
step to me?
If we need exact-width interger we should use uintNN_t
but I don't think exact width is required in locale.
As other guys say we can't assume uint8_t == unsigned char implicitly:
On Sun, 06 Jun 2010, Izumi Tsutsui wrote:
If we need exact-width interger we should use uintNN_t
but I don't think exact width is required in locale.
The [u]int_leastN_t types may be useful in this sort of code. For
example, [u]int_least32_t is required to exist, and on a 36-bit machine
it
hi, all
I was just wondering why this change was made? It seems to be a backwards
step to me?
my intension is quite paranoia.
changing uint8_t - unsigned char / int16_t - short is because
_ctype_ / _tolower_tab_ / _toupper_tab_ in ctype.h (now splitted
sys/ctype_bits.h)
declared as unsigned
Hi Nozaki-san,
On Wed, Jun 02, 2010 at 04:04:52PM +, Takehiko NOZAKI wrote:
Module Name: src
Committed By: tnozaki
Date: Wed Jun 2 16:04:52 UTC 2010
Modified Files:
src/lib/libc/locale: bsdctype.c
Log Message:
uint8_t - unsigned char, int16_t - short.
As ever,
On Sat, Jun 05, 2010 at 11:53:32PM +0200, Alistair Crooks wrote:
Module Name: src
Committed By: tnozaki
Date: Wed Jun 2 16:04:52 UTC 2010
Modified Files:
src/lib/libc/locale: bsdctype.c
Log Message:
uint8_t - unsigned char, int16_t - short.
In message: 20100606041254.gb19...@netbsd.org
David Holland dholland-sourcechan...@netbsd.org writes:
: On Sat, Jun 05, 2010 at 11:53:32PM +0200, Alistair Crooks wrote:
:Module Name: src
:Committed By:tnozaki
:Date:Wed Jun 2 16:04:52 UTC 2010
:
:
On Sat, Jun 05, 2010 at 11:28:31PM -0600, M. Warner Losh wrote:
: I looked at it and it appears to me that it's a change to use
: non-sized types (that are guaranteed to be large enough) in the
: in-memory structures. If we ever do a port to a 36-bit machine or
: whatever it's probably
22 matches
Mail list logo
