1 |
1325 |
phoenix |
uClibc attempts to fully (and rigorously) support "The Open Group Base
|
2 |
|
|
Specifications Issue 6 IEEE Std 1003.1, 2003 Edition" (aka SuSv3). However, as
|
3 |
|
|
with any standard, they sometimes require things that are either impossible or
|
4 |
|
|
are Completely Stupid(tm). Therefore, we cannot claim full compliance, and
|
5 |
|
|
there may be some area of uClibc that differ from the requirements of this
|
6 |
|
|
specification. This document attempts to list these differences and, when
|
7 |
|
|
completed, will contain a full list of all relevant differences between uClibc
|
8 |
|
|
and the requirements of the SuSv3.
|
9 |
|
|
|
10 |
|
|
|
11 |
|
|
1) The uClibc setlocale() function is not threadsafe.
|
12 |
|
|
|
13 |
|
|
SuSv3 states that "The locale state is common to all threads
|
14 |
|
|
within a process.". But it does not explicitly mention
|
15 |
|
|
setlocale() as a function that need not be thread-safe.
|
16 |
|
|
Making setlocale() threadsafe would require an absurd amount
|
17 |
|
|
of locking (i.e. inside each and every ctype call such as
|
18 |
|
|
isalpha()). Furthermore, we consider calling setlocale()
|
19 |
|
|
from N threads concurrently while using string functions to
|
20 |
|
|
be a terribly dumb thing to do. Therefore, we have decided
|
21 |
|
|
that setlocale() shall not be threadsafe. If you are
|
22 |
|
|
multi-threaded, and you wish to change the global locale
|
23 |
|
|
state, please take care to prevent all other threads from
|
24 |
|
|
using any locale or ctype functions until the setlocale()
|
25 |
|
|
call has finished.
|
26 |
|
|
|
27 |
|
|
2) Some functions required by SuSv3 are not currently implemented.
|
28 |
|
|
Functions listed by SuSv3 but not (yet) included in uClibc:
|
29 |
|
|
|
30 |
|
|
fmtmsg
|
31 |
|
|
|
32 |
|
|
|
33 |
|
|
|
34 |
|
|
More to follow when we think of it...
|
35 |
|
|
|