OpenCores
URL https://opencores.org/ocsvn/or1k/or1k/trunk

Subversion Repositories or1k

[/] [or1k/] [trunk/] [linux/] [uClibc/] [docs/] [Glibc_vs_uClibc_Differences.txt] - Blame information for rev 1771

Go to most recent revision | Details | Compare with Previous | View Log

Line No. Rev Author Line
1 1325 phoenix
 uClibc and Glibc are not the same -- there are a number of differences which
2
may or may not cause you problems.  This document attempts to list these
3
differences and, when completed, will contain a full list of all relevant
4
differences.
5
 
6
 
7
1) uClibc is smaller than glibc.  We attempt to maintain a glibc compatible
8
interface, allowing applications that compile with glibc to easily compile with
9
uClibc.  However, we do not include _everything_ that glibc includes, and
10
therefore some applications may not compile.  If this happens to you, please
11
report the failure to the uclibc mailing list, with detailed error messages.
12
 
13
2) uClibc is much more configurable then glibc.  This means that a developer
14
may have compiled uClibc in such a way that significant amounts of
15
functionality have been omitted.
16
 
17
3) uClibc does not even attempt to ensure binary compatibility across releases.
18
When a new version of uClibc is released, you may or may not need to recompile
19
all your binaries.
20
 
21
4) malloc(0) in glibc returns a valid pointer to something(!?!?) while in
22
uClibc calling malloc(0) returns a NULL.  The behavior of malloc(0) is listed
23
as implementation-defined by SuSv3, so both libraries are equally correct.
24
This difference also applies to realloc(NULL, 0).  I personally feel glibc's
25
behavior is not particularly safe.  To enable glibc behavior, one has to
26
explicitly enable the MALLOC_GLIBC_COMPAT option.
27
 
28
4.1) glibc's malloc() implementation has behavior that is tunable via the
29
MALLOC_CHECK_ environment variable.  This is primarily used to provide extra
30
malloc debugging features.  These extended malloc debugging features are not
31
available within uClibc.  There are many good malloc debugging libraries
32
available for Linux (dmalloc, electric fence, valgrind, etc) that work much
33
better than the glibc extended malloc debugging.  So our omitting this
34
functionality from uClibc is not a great loss.
35
 
36
5) uClibc does not provide a database library (libdb).
37
 
38
6) uClibc does not support NSS (/lib/libnss_*), which allows glibc to easily
39
support various methods of authentication and DNS resolution.  uClibc only
40
supports flat password files and shadow password files for storing
41
authentication information.  If you need something more complex than this,
42
you can compile and install pam.
43
 
44
7) uClibc's libresolv is only a stub.  Some, but not all of the functionality
45
provided by glibc's libresolv is provided internal to uClibc.  Other functions
46
are not at all implemented.
47
 
48
8) libnsl provides support for Network Information Service (NIS) which was
49
originally called "Yellow Pages" or "YP", which is an extension of RPC invented
50
by Sun to share Unix password files over the network.  I personally think NIS
51
is an evil abomination and should be avoided.  These days, using ldap is much
52
more effective mechanism for doing the same thing.  uClibc provides a stub
53
libnsl, but has no actual support for Network Information Service (NIS).
54
We therefore, also do not provide any of the headers files provided by glibc
55
under /usr/include/rpcsvc.   I am open to implementing ldap based password
56
authentication, but I do not personally intend to implement it (since I have no
57
use for it).
58
 
59
9) uClibc's locale support is not 100% complete yet.  We are working on it.
60
 
61
10) uClibc's math library only supports long double as inlines, and even
62
then the long double support is quite limited.
63
 
64
11) uClibc's libcrypt does not support the reentrant crypt_r, setkey_r and
65
encrypt_r, since these are not required by SuSv3.
66
 
67
12) uClibc directly uses the kernel types to define most opaque data types.
68
 
69
13) uClibc directly uses the linux kernel's arch specific 'stuct stat'.
70
 
71
72
 
73
 
74
 
75
******************************  Manuel's Notes  ******************************
76
 
77
Some general comments...
78
 
79
The intended target for all my uClibc code is ANSI/ISO C99 and SUSv3
80
compliance.  While some glibc extensions are present, many will eventually
81
be configurable.  Also, even when present, the glibc-like extensions may
82
differ slightly or be more restrictive than the native glibc counterparts.
83
They are primarily meant to be porting _aides_ and not necessarily
84
drop-in replacements.
85
 
86
Now for some details...
87
 
88
time functions
89
--------------
90
1) Leap seconds are not supported.
91
2) /etc/timezone and the whole zoneinfo directory tree are not supported.
92
   To set the timezone, set the TZ environment variable as specified in
93
   http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap08.html
94
   or you may also create an /etc/TZ file of a single line, ending with a
95
   newline, containing the TZ setting.  For example
96
   echo CST6CDT > /etc/TZ
97
3) Currently, locale specific eras and alternate digits are not supported.
98
   They are on my TODO list.
99
 
100
wide char support
101
-----------------
102
1) The only multibyte encoding currently supported is UTF-8.  The various
103
   ISO-8859-* encodings are (optionally) supported.  The internal
104
   representation of wchar's is assumed to be 31 bit unicode values in
105
   native endian representation.  Also, the underlying char encoding is
106
   assumed to match ASCII in the range 0-0x7f.
107
2) In the next iteration of locale support, I plan to add support for
108
   (at least some) other multibyte encodings.
109
 
110
locale support
111
--------------
112
1) The target for support is SUSv3 locale functionality.  While nl_langinfo
113
   has been extended, similar to glibc, it only returns values for related
114
   locale entries.
115
2) Currently, all SUSv3 libc locale functionality should be implemented
116
   except for wcsftime and collating item support in regex.
117
 
118
stdio
119
-----
120
1) Conversion of large magnitude floating-point values by printf suffers a loss
121
   of precision due to the algorithm used.
122
2) uClibc's printf is much stricter than glibcs, especially regarding positional
123
   args.  The entire format string is parsed first and an error is returned if
124
   a problem is detected.  In locales other than C, the format string is checked
125
   to be a valid multibyte sequence as well.  Also, currently at most 10 positional
126
   args are allowed (although this is configurable).
127
3) BUFSIZ is configurable, but no attempt is made at automatic tuning of internal
128
   buffer sizes for stdio streams.  In fact, the stdio code in general sacrifices
129
   sophistication/performace for minimal size.
130
4) uClibc allows glibc-like custom printf functions.  However, while not
131
   currently checked, the specifier must be <= 0x7f.
132
5) uClibc allows glibc-like custom streams.  However, no in-buffer seeking is
133
   done.
134
6) The functions fcloseall() and __fpending() can behave differently than their
135
   glibc counterparts.
136
7) uClibc's setvbuf is more restrictive about when it can be called than glibc's
137
   is.  The standards specify that setvbuf must occur before any other operations
138
   take place on the stream.
139
8) Right now, %m is not handled properly by printf when the format uses positional
140
   args.
141
9) The FILEs created by glibc's fmemopen(), open_memstream(), and fopencookie()
142
   are not capable of wide orientation.  The corresponding uClibc routines do
143
   not have this limitation.
144
10) For scanf, the C99 standard states "The fscanf function returns the value of
145
    the macro EOF if an input failure occurs before any conversion."  But glibc's
146
    scanf does not respect conversions for which assignment was surpressed, even
147
    though the standard states that the value is converted but not stored.
148
 
149
glibc bugs that Ulrich Drepper has refused to acknowledge or comment on
150
  ( http://sources.redhat.com/ml/libc-alpha/2003-09/ )
151
-----------------------------------------------------------------------
152
1) The C99 standard says that for printf, a %s conversion makes no special
153
   provisions for multibyte characters.  SUSv3 is even more clear, stating
154
   that bytes are written and a specified precision is in bytes.  Yet glibc
155
   treats the arg as a multibyte string when a precision is specified and
156
   not otherwise.
157
2) Both C99 and C89 state that the %c conversion for scanf reads the exact
158
   number of bytes specified by the optional field width (or 1 if not specified).
159
   uClibc complies with the standard.  There is an argument that perhaps the
160
   specified width should be treated as an upper bound, based on some historical
161
   use.  However, such behavior should be mentioned in the Conformance document.
162
3) glibc's scanf is broken regarding some numeric patterns.  Some invalid
163
   strings are accepted as valid ("0x.p", "1e", digit grouped strings).
164
   In spite of my posting examples clearly illustrating the bugs, they remain
165
   unacknowledged by the glibc developers.
166
4) glibc's scanf seems to require a 'p' exponent for hexadecimal float strings.
167
   According to the standard, this is optional.
168
5) C99 requires that once an EOF is encountered, the stream should be treated
169
   as if at end-of-file even if more data becomes available.  Further reading
170
   can be attempted by clearing the EOF flag though, via clearerr() or a file
171
   positioning function.  For details concerning the original change, see
172
   Defect Report #141.  glibc is currently non-compliant, and the developers
173
   did not comment when I asked for their official position on this issue.
174
6) glibc's collation routines and/or localedef are broken regarding implicit
175
   and explicit UNDEFINED rules.
176
 
177
More to follow as I think of it...

powered by: WebSVN 2.1.0

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.