Bug 172215 - localeconv() grouping appears not to match POSIX
Summary: localeconv() grouping appears not to match POSIX
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: standards (show other bugs)
Version: 9.0-STABLE
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-standards mailing list
URL:
Keywords: patch
Depends on:
Blocks:
 
Reported: 2012-10-01 16:50 UTC by Ed Maste
Modified: 2019-09-11 07:26 UTC (History)
2 users (show)

See Also:


Attachments
file.diff (419 bytes, patch)
2012-10-01 16:50 UTC, Ed Maste
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
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 freebsd_triage 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