Project

General

Profile

Bug #3231

C locale grouping definitions differ from documentation

Added by Albert Lee about 8 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
locale - data and messages
Start date:
2012-09-26
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
Gerrit CR:

Description

localeconv(3c) states that the C locale values for the returned struct lconv include:

       char *decimal_point;        /* "." */
       char *thousands_sep;        /* "" (zero length string) */
       char *grouping;             /* "" */
       char *int_curr_symbol;      /* "" */
       char *currency_symbol;      /* "" */
       char *mon_decimal_point;    /* "" */
       char *mon_thousands_sep;    /* "" */
       char *mon_grouping;         /* "" */

Whereas our real locale definitions inherited from FreeBSD use the char array { CHAR_MAX, '\0' } instead of the empty string for the grouping and mon_grouping members. See
http://src.illumos.org/source/xref/illumos-gate/usr/src/lib/libc/port/locale/lmonetary.c#numempty and http://src.illumos.org/source/xref/illumos-gate/usr/src/lib/libc/port/locale/lnumeric.c#numempty

The groupings are interpreted as arrays of byte values rather than characters and CHAR_MAX disables grouping, while an empty string, while documented in our manpages and suggested by the specification, produces undefined behaviour. The inconsistency was noticed when porting GNU grep, as their tests assume these lconv members use the empty string and disable their tests for FreeBSD in specific.

https://jserver.opengroup.org/pr/public/openbrand/PRView?PR=0164 has some additional clarification about the implications of allowing empty string for the grouping values. While there is no resolution for the conflict yet, both values are accepted for conformance testing.

No data to display

Also available in: Atom PDF