Commit Graph

5 Commits

Author SHA1 Message Date
Andrey A. Chernov
96be743f80 According to Garrett, POSIX widely use -1 to indicate CHAR_MAX, so back out
all my "-1" -> "something" fixes and replace -1 with CHAR_MAX directly in
strtol() in cnv()
2001-02-10 03:31:23 +00:00
Andrey A. Chernov
d2712eafa7 Use __XSTRING(CHAR_MAX) instead of "127" and strtol() base 0 to parse it (0x7f) 2001-02-10 02:00:56 +00:00
Andrey A. Chernov
1506a668dc Correct myself a bit: situation is broken not for _all_ numeric LC_MONETARY,
LC_NUMERIC fields, but only for *grouping fields - other fields are converted
to a chars in localeconv(), so final change is:

"-1" -> "127"

127 here is because CHAR_MAX supposed, which is _positive_ (SUSv2 requirement),
not negative as 255. It is still a bit of hack. To find real CHAR_MAX will be
better to sprintf() it once somewhere in static buffer. *grouping parsing
still broken and missing and needs to be implemented.
2001-02-10 01:38:18 +00:00
Andrey A. Chernov
051f867fe1 NOTE: according to SUSV2 and other implementations, numeric elements in
LC_MONETARY, LC_NUMERIC are byte-arrays, not ASCII strings!

Fix "C" locale, change "-1" to {CHAR_MAX, '\0'} according to standards.

This is only partial fix - locale loading procedure remains broken as before
and load too big values for all locales.  All numeric strings there should be
converted with something like atoi() and placed into bytes.  Maybe I do it
later, if someone will not fix it faster.
2001-02-10 00:43:32 +00:00
Alexey Zelkin
90423ececf Make FreeBSD locale support complete: add support for rest locale categories
LC_MONETARY, LC_NUMERIC and LC_MESSAGES. Remove stub functions since they
don't need anymore.

Reviewed by:	silence on -i18n
2001-02-08 16:58:53 +00:00