[Bug localedata/16782] New: RFE: Minimum number to apply separator

[Bug localedata/16782] New: RFE: Minimum number to apply separator

[myllynen at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=16782

            Bug ID: 16782
           Summary: RFE: Minimum number to apply separator
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: localedata
          Assignee: unassigned at sourceware dot org
          Reporter: myllynen at redhat dot com
                CC: libc-locales at sourceware dot org

In some locales it would be desirable to allow start using separator only at
certain lenght, for example separator is not wanted under 10000 in pl_PL. This
would probably be wanted only for LC_NUMERIC.

See https://sourceware.org/bugzilla/show_bug.cgi?id=16777 for additional
discussion.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug localedata/16782] RFE: Minimum number to apply separator

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=16782

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|                            |security-

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug localedata/16782] RFE: Minimum number to apply separator

[piotrdrag at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=16782

Piotr Drąg <piotrdrag at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |piotrdrag at gmail dot com

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-30061-listarch-glibc-bugs=sources.redhat.com@sourceware.org Wed Oct 07 13:38:06 2015
Return-Path: <glibc-bugs-return-30061-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 49024 invoked by alias); 7 Oct 2015 13:38:05 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 48665 invoked by uid 48); 7 Oct 2015 13:38:01 -0000
From: "piotrdrag at gmail dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug localedata/16777] Incorrect thousands separator in pl_PL locale
Date: Wed, 07 Oct 2015 13:38:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: localedata
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: piotrdrag at gmail dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: security-
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-16777-131-0ioB40I78r@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-16777-131@http.sourceware.org/bugzilla/>
References: <bug-16777-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-10/txt/msg00098.txt.bz2
Content-length: 400

https://sourceware.org/bugzilla/show_bug.cgi?id=16777

Piotr Drąg <piotrdrag at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |piotrdrag at gmail dot com

-- 
You are receiving this mail because:
You are on the CC list for the bug.
>From glibc-bugs-return-30063-listarch-glibc-bugs=sources.redhat.com@sourceware.org Wed Oct 07 14:06:03 2015
Return-Path: <glibc-bugs-return-30063-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 90710 invoked by alias); 7 Oct 2015 14:06:02 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 90617 invoked by uid 48); 7 Oct 2015 14:05:59 -0000
From: "carlos at redhat dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug libc/6399] gettid() should have a wrapper
Date: Wed, 07 Oct 2015 14:06:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: libc
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: carlos at redhat dot com
X-Bugzilla-Status: REOPENED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: security-
X-Bugzilla-Changed-Fields:
Message-ID: <bug-6399-131-le2AqlezIX@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-6399-131@http.sourceware.org/bugzilla/>
References: <bug-6399-131@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-10/txt/msg00100.txt.bz2
Content-length: 1458

https://sourceware.org/bugzilla/show_bug.cgi?idc99

--- Comment #41 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Florian Weimer from comment #40)
> We are committed to a 1:1 threading model because userspace code manipulates
> task attributes such as CPU affinity or capabilities, and all kinds of
> things will break if we start switching userspace threads to different
> (still userspace, obviously) kernel tasks.  (Restoring all those attributes
> on context switch is not possible for performance reasons.)
>
> This means that Ulrich's objection to adding gettid is no longer valid.

I've talked about this a bit before, and I'll mention it again for good
measure.

The biggest problem is that the design in Linux for this stinks. The reuse of
pid_t as a type for tid's is confusing IMO and was a design flaw.

Therefore if we are to carry this out we need to thoroughly think about what it
means to expose a tid, should we use a distinct type, what is that type going
to look like? Should users be able to convert from pthread_t to to tid_t and
vice versa? Do we want new interfaces that take tid_t types for all those
things you'd do with native threads or should the interfaces that take pid_t
document their support for being called with tid_t values?

Either way, someone needs to start with a coherent design for what this is
going to look like.

--
You are receiving this mail because:
You are on the CC list for the bug.

[Bug localedata/16782] RFE: Minimum number to apply separator

[egmont at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=16782

Egmont Koblinger <egmont at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |egmont at gmail dot com

--- Comment #1 from Egmont Koblinger <egmont at gmail dot com> ---
Just FYI:

In hu_HU the separator (space or dot) is also to be used for numbers of at
least 5 digits, with the exception that if 4-digit numbers and 5+-digit numbers
are mixed in a vertical listing then 4-digit ones also get the separator.

I think it's a reasonable expectation in other locales as well for an app to be
able to nicely format a column a numbers, and for that, if this feature is
implemented then there should be some means by which printf can disable this 
conditional.

If I had to choose between the current behavior, or the correct behavior
without having this possibility to make an exception, I'd say I'd probably
choose the former one. That is, I believe implementing this feature without
this extra possibility would cause more harm than good.

Source: the official Hungarian orthograpry rules at
http://helyesiras.mta.hu/helyesiras/default/akh12, bullet point 291/b [in
Hungarian]. The HTML layout is broken here, in the printed book (I have one on
my bookshelf) the column of numbers is right-aligned with the separator spaces
exactly above each other as it makes sense.

Another thing to consider: Is the boundary necessarily a certain number of
digits, rather than some certain value in between? E.g. is it possible that a
language starts inserting the separator from let's say 2000?

-- 
You are receiving this mail because:
You are on the CC list for the bug.