https://sourceware.org/bugzilla/show_bug.cgi?id=16777 Marko Myllynen changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |myllynen at redhat dot com --- Comment #1 from Marko Myllynen --- (In reply to MichaÅ‚ GÃ³rny from comment #0) > Currently, glibc lists the following for pl_PL locale: > > - no thousands separator in LC_NUMERIC section, > > - '.' as thousands separator in LC_MONETARY section. > > While actually, a non-breaking space is used as thousands separator in both > cases. However, I'm not sure if it is correct to use in locales or > if should be used instead. <00A0> should be used in this case, as do many other locales as well. > It should be also noted that the grouping is used only for numbers having > more than 4 digits, i.e. '4000' does not use grouping, '40 000' and '4 000 > 000' do on 3-digit groups. I don't know if it is possible to express this in > current glibc localedata format. Perhaps you want to see whether that's doable, please see the Locales wiki page which has a link to a page describing LC_NUMERIC and grouping in detail. The page contains also information on how to test and submit your locale changes. Thanks. -- You are receiving this mail because: You are on the CC list for the bug. >From glibc-bugs-return-22037-listarch-glibc-bugs=sources.redhat.com@sourceware.org Mon Mar 31 10:45:25 2014 Return-Path: Delivered-To: listarch-glibc-bugs@sources.redhat.com Received: (qmail 19940 invoked by alias); 31 Mar 2014 10:45:24 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Delivered-To: mailing list glibc-bugs@sourceware.org Received: (qmail 19860 invoked by uid 55); 31 Mar 2014 10:45:18 -0000 From: "keld at keldix dot com" To: glibc-bugs@sourceware.org Subject: [Bug localedata/16777] Incorrect thousands separator in pl_PL locale Date: Mon, 31 Mar 2014 10:45: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: keld at keldix dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: 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: 2014-03/txt/msg00228.txt.bz2 Content-length: 2626 https://sourceware.org/bugzilla/show_bug.cgi?id=16777 --- Comment #2 from keld at keldix dot com --- On Mon, Mar 31, 2014 at 07:10:18AM +0000, myllynen at redhat dot com wrote: > https://sourceware.org/bugzilla/show_bug.cgi?id=16777 > > Marko Myllynen changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |myllynen at redhat dot com > > --- Comment #1 from Marko Myllynen --- > (In reply to Micha?? GÃ³rny from comment #0) > > Currently, glibc lists the following for pl_PL locale: > > > > - no thousands separator in LC_NUMERIC section, > > > > - '.' as thousands separator in LC_MONETARY section. > > > > While actually, a non-breaking space is used as thousands separator in both > > cases. However, I'm not sure if it is correct to use in locales or > > if should be used instead. > > <00A0> should be used in this case, as do many other locales as well. > > > It should be also noted that the grouping is used only for numbers having > > more than 4 digits, i.e. '4000' does not use grouping, '40 000' and '4 000 > > 000' do on 3-digit groups. I don't know if it is possible to express this in > > current glibc localedata format. > > Perhaps you want to see whether that's doable, please see the Locales wiki page > which has a link to a page describing LC_NUMERIC and grouping in detail. The > page contains also information on how to test and submit your locale changes. I do not think the "under 10000" is doable with current glibc functionality. furthermore I think this is not desirable, for LC_MONETARY. The no break space versus the COMMA/PERIOD thousands separator issue is a classical problem between linguistic and computer use. Linguists tends in many languages, European style, to advocate no break space, but for computer use a period is most often used. I have yet to see a financial application to use no break space. Bank applications and ledger applications do not use no break space. Actually we shoud probably provide for both styles, and also do the "no separator for under 10000.". I would then advise that we use the current functionality in the POSIX style, and compatible with the POSIX/C locale, and then have new keywords both in LC_MONETARY and LC_NUMERIC for the linguistic styles. Best regards Keld -- You are receiving this mail because: You are on the CC list for the bug. >From glibc-bugs-return-22038-listarch-glibc-bugs=sources.redhat.com@sourceware.org Mon Mar 31 12:52:52 2014 Return-Path: Delivered-To: listarch-glibc-bugs@sources.redhat.com Received: (qmail 2478 invoked by alias); 31 Mar 2014 12:52:52 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Delivered-To: mailing list glibc-bugs@sourceware.org Received: (qmail 2435 invoked by uid 55); 31 Mar 2014 12:52:47 -0000 From: "cvs-commit at gcc dot gnu.org" To: glibc-bugs@sourceware.org Subject: [Bug libc/16648] [microblaze] __ASSUME_ATFCTS incorrect (futimesat) Date: Mon, 31 Mar 2014 12:52: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: 2.19 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: cvs-commit at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: 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: 2014-03/txt/msg00229.txt.bz2 Content-length: 3163 https://sourceware.org/bugzilla/show_bug.cgi?id648 --- Comment #1 from cvs-commit at gcc dot gnu.org --- This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "GNU C Library master sources". The branch, master has been updated via d7a68734f7bbc76586017461cff19af0d9cb4df8 (commit) from c760f5c210d85247ef0c6e10f7ef44fa27d9bd1d (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- https://sourceware.org/git/gitweb.cgi?p=glibc.git;h×a68734f7bbc76586017461cff19af0d9cb4df8 commit d7a68734f7bbc76586017461cff19af0d9cb4df8 Author: Joseph Myers Date: Mon Mar 31 12:51:45 2014 +0000 Fix futimesat for older MicroBlaze kernels (bug 16648). Continuing the fixes for __ASSUME_* issues in preparation for moving to a 2.6.32 minimum kernel version, this *untested* patch fixes bug 16648, the definition of __ASSUME_ATFCTS meaning that the futimesat syscall is assumed for all MicroBlaze kernels despite not being present until 2.6.33. __ASSUME_ATFCTS controls conditionals relating to a lot of different syscalls in Linux-specific code (fstatat64 faccessat fchmodat fchownat futimesat newfstatat linkat mkdirat openat readlinkat renameat symlinkat unlinkat mknodat), where whether newfstatat fstatat64 futimesat are used depends on the architecture, as well as controlling whether openat64_not_cancel_3 is expected to work in sysdeps/posix/getcwd.c. The assumptions are all OK as of 2.6.32 except for this MicroBlaze case, and it's generally desirable to get rid of as many of the __ASSUME_ATFCTS conditionals as possible, to simplify the code (the fallbacks include potential unbounded dynamic stack allocations). Thus, rather than the simplest approach of undefining __ASSUME_ATFCTS for older kernels on MicroBlaze, this patch takes the approach of using the linux-generic implementation of futimesat for MicroBlaze kernels before 2.6.33 (all such kernels have the utimensat syscall). [BZ #16648] * sysdeps/unix/sysv/linux/microblaze/kernel-features.h [__LINUX_KERNEL_VERSION >= 0x020621] (__ASSUME_FUTIMESAT): Define. * sysdeps/unix/sysv/linux/microblaze/futimesat.c: New file. ----------------------------------------------------------------------- Summary of changes: ChangeLog | 7 ++++++ NEWS | 6 ++-- .../sysv/linux/microblaze/futimesat.c} | 21 +++++++++---------- .../unix/sysv/linux/microblaze/kernel-features.h | 5 ++++ 4 files changed, 25 insertions(+), 14 deletions(-) copy sysdeps/{powerpc/powerpc64/multiarch/strcspn.c => unix/sysv/linux/microblaze/futimesat.c} (64%) -- You are receiving this mail because: You are on the CC list for the bug.