was in. This shall be MFC'd in about three days (probably not a good idea
to MFC the stylistic changes though - see below).
PR: 19978
Submitted by: Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at>
Patch by: roam (slightly modified by me to use NULL not NIL)
user confusion, so specify it directly, i.e. change "3" to "3;0".
In this style "3;" or "3" must not cause repeating
(converted to \3, CHAR_MAX, \0)
Still not implemented and broken in localeconv()
user confusion, so specify it directly, i.e. change "3" to "3;0".
In this style "3;" must not cause repeating (converted to \3, CHAR_MAX, \0)
NOTE: still no proper conversion done in localeconv()
it as I was playing with some other ways of doing kernel preemption.
You must still specify the PREEMPTION option in your config file to get a
preemptive kernel.
repeated forever according to SUSv2
Remove "0;0" - \0 means not "no grouping" but repeat forever previous char,
and added automatically. Empty string could be parsed later into CHAR_MAX
(real "no grouping") by localeconv()
attributes. This is needed for AST's to be properly posted in a preemptive
kernel. They are backed by two new flags in p_sflag: PS_ASTPENDING and
PS_NEEDRESCHED. They are still accesssed by their old macros:
aston(), astoff(), etc. For completeness, an astpending() macro has been
added to check for a pending AST, and clear_resched() has been added to
clear need_resched().
- Rename syscall2() on the x86 back to syscall() to be consistent with
other architectures.
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.
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.
en_CA, en_GB => en_US
en_AU, en_NZ => en_GB
fr_CA, fr_CH => fr_FR
There are separate links for `GB English' and `US English' because I
anticipate users of the former to potentially want a thousands_sep of
" " (to match modern British style) rather than ",".
XXX What about en_IE? ISO_8859-15?
