Bug 172215

Summary:

localeconv() grouping appears not to match POSIX

Product:

Base System

Reporter:

Ed Maste <emaste>

Component:

standards

Assignee:

Ed Maste <emaste>

Status:

Closed FIXED

Severity:

Affects Only Me

CC:

theraven, yuripv

Priority:

Normal

Keywords:

patch

Version:

9.0-STABLE

Hardware:

Any

OS:

Any

Attachments:

Description	Flags
file.diff	none

Description Ed Maste freebsd_committer

2012-10-01 16:50:02 UTC

I can find two references to the expected return from localeconv() for
grouping / mon_grouping.  First, the behaviour in SUSv2
http://pubs.opengroup.org/onlinepubs/007908799/xbd/locale.html matches what
FreeBSD currently does -- { CHAR_MAX, '\0' }:

  The third column shows the equivalent string in the ISO C standard that
  would be used by the localeconv() function to accommodate this grouping

  mon_grouping   Formatted Value   ISO C String
  -1             123456789         "\177" 

In 1003.1 (2004) for POSIX Locale
http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap07.html
it suggests that the return should be empty string:

               langinfo   POSIX Locale   localeconv()   localedef
Item           Constant      Value           Value        Value
mon_grouping       -          N/A             ""           -1

This came up on the gnulib mailing list recently, which has a testcase
for localeconv that contains #ifdef'd-out cases for l->grouping and
l->mon_gropuing on FreeBSD.

http://lists.gnu.org/archive/html/bug-gnulib/2012-08/msg00142.html

Fix: I suspect this could be accomplished with the following patch:

Comment 1 David Chisnall freebsd_committer

2014-06-02 08:48:46 UTC

This looks correct, and may account for a couple of the libc++ test failures.  I'm not sure what the ports fallout for the fix would be though.  The -1, "" case seems more sensible because it means that callers don't need to special case the no-grouping case (-1, "" means treat all remaining characters as having no grouping)

Comment 2 Eitan Adler freebsd_committer

2018-05-23 10:27:36 UTC

batch change of PRs untouched in 2018 marked "in progress" back to open.

Comment 3 Yuri Pankov freebsd_committer

2019-09-10 18:56:34 UTC

I stumbled upon this issue while looking into locale(1) reporting incorrect values (i.e. 127 instead of -1 for a lot of keywords), and indeed localeconv() returns not what one would expect reading https://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap07.html.

For the locale(1), I'll just check for 127, but for the ports, I doubt the fallout from fixing this could ever be tested by exp-run as a lot of projects could just #ifdef us and expect "\177", those would still compile, but misbehave.

Comment 4 Baptiste Daroussin freebsd_committer

2019-09-11 07:26:15 UTC

Any progress on this one? we imho need this patch to be committed

Comment 5 commit-hook freebsd_committer

2019-12-19 17:02:19 UTC

A commit references this bug:

Author: emaste
Date: Thu Dec 19 17:01:26 UTC 2019
New revision: 355914
URL: https://svnweb.freebsd.org/changeset/base/355914

Log:
  localeconv: correct grouping and mon_grouping per C/POSIX

  grouping and mon_grouping should be "" in the C locale.

  PR:		172215
  MFC after:	6 weeks
  Sponsored by:	The FreeBSD Foundation

Changes:
  head/lib/libc/locale/fix_grouping.c

Comment 6 commit-hook freebsd_committer

2020-03-08 18:10:20 UTC

A commit references this bug:

Author: emaste
Date: Sun Mar  8 18:09:41 UTC 2020
New revision: 358751
URL: https://svnweb.freebsd.org/changeset/base/358751

Log:
  MFC r355914: localeconv: correct grouping and mon_grouping per C/POSIX

  grouping and mon_grouping should be "" in the C locale.

  PR:		172215
  Sponsored by:	The FreeBSD Foundation

Changes:
_U  stable/12/
  stable/12/lib/libc/locale/fix_grouping.c