<commit_before> uClibc and Glibc are not the same -- there are a number of differences which
may or may not cause you problems.  This document attempts to list these
differences and, when completed, will contain a full list of all relevant
differences.


1) uClibc is smaller than glibc.  We attempt to maintain a glibc compatible
interface, allowing applications that compile with glibc to easily compile with
uClibc.  However, we do not include _everything_ that glibc includes, and
therefore some applications may not compile.  If this happens to you, please
report the failure to the uclibc mailing list, with detailed error messages.

2) uClibc is much more configurable then glibc.  This means that a developer
may have compiled uClibc in such a way that significant amounts of
functionality have been omitted.  

3) uClibc does not even attempt to ensure binary compatibility across releases.
When a new version of uClibc is released, you may or may not need to recompile
all your binaries.

4) malloc(0) in glibc returns a valid pointer to something(!?!?) while in
uClibc calling malloc(0) returns a NULL.  The behavior of malloc(0) is listed
as implementation-defined by SuSv3, so both libraries are equally correct.
This difference also applies to realloc(NULL, 0).  I personally feel glibc's
behavior is not particularly safe.

5) uClibc does not provide a database library (libdb).

6) uClibc does not support NSS (/lib/libnss_*), which allows glibc to easily
support various methods of authentication and DNS resolution.  uClibc only
supports flat password files and shadow password files for storing
authentication information.

7) uClibc's libresolv is only a stub.  Some, but not all of the functionality
provided by glibc's libresolv is provided internal to uClibc.  Other functions
are not at all implemented.

8) uClibc does not provide libnsl.so.1, and has no support for Network
Information Service (NIS).  We therefore, also do not provide any of the 
headers files provided by glibc under /usr/include/rpcsvc.

9) uClibc's locale support is not 100% complete yet.  We are working on it.

10) uClibc's math library only supports long double as inlines, and even
then the long double support is quite limited.

11) uClibc's libcrypt does not support the reentrant crypt_r, setkey_r and
encrypt_r, since these are not required by SuSv3.

12) uClibc does not implement wordexp()


13) uClibc directly uses the kernel types to define most opaque data types.

14) uClibc directly uses the linux kernel's arch specific 'stuct stat'.

15) Add other things here as they come up......



******************************  Manuel's Notes  ******************************

Some general comments...

The intended target for all my uClibc code is ANSI/ISO C99 and SUSv3
compliance.  While some glibc extensions are present, many will eventually
be configurable.  Also, even when present, the glibc-like extensions may
differ slightly or be more restrictive than the native glibc counterparts.
They are primarily meant to be porting _aides_ and not necessarily
drop-in replacements.
<commit_msg>Update verbage regarding NIS<commit_after> uClibc and Glibc are not the same -- there are a number of differences which
may or may not cause you problems.  This document attempts to list these
differences and, when completed, will contain a full list of all relevant
differences.


1) uClibc is smaller than glibc.  We attempt to maintain a glibc compatible
interface, allowing applications that compile with glibc to easily compile with
uClibc.  However, we do not include _everything_ that glibc includes, and
therefore some applications may not compile.  If this happens to you, please
report the failure to the uclibc mailing list, with detailed error messages.

2) uClibc is much more configurable then glibc.  This means that a developer
may have compiled uClibc in such a way that significant amounts of
functionality have been omitted.  

3) uClibc does not even attempt to ensure binary compatibility across releases.
When a new version of uClibc is released, you may or may not need to recompile
all your binaries.

4) malloc(0) in glibc returns a valid pointer to something(!?!?) while in
uClibc calling malloc(0) returns a NULL.  The behavior of malloc(0) is listed
as implementation-defined by SuSv3, so both libraries are equally correct.
This difference also applies to realloc(NULL, 0).  I personally feel glibc's
behavior is not particularly safe.

5) uClibc does not provide a database library (libdb).

6) uClibc does not support NSS (/lib/libnss_*), which allows glibc to easily
support various methods of authentication and DNS resolution.  uClibc only
supports flat password files and shadow password files for storing
authentication information.

7) uClibc's libresolv is only a stub.  Some, but not all of the functionality
provided by glibc's libresolv is provided internal to uClibc.  Other functions
are not at all implemented.

8) libnsl provides support for Network Information Service (NIS) which was
originally called "Yellow Pages" or "YP"), which is an extension of RPC
invented by Sun to share Unix password files over the network.  I personally
think NIS is an evil abomination, and should be avoided.  These days, using
ldap is much more effective mechanism for doing the same thing.  uClibc does
not provide libnsl.so.1, and has no support for Network Information Service
(NIS).  We therefore, also do not provide any of the headers files provided by
glibc under /usr/include/rpcsvc.   I am open to implementing ldap based
password authentication, but I do not personally intend to implement it (since
I have no use for it).

9) uClibc's locale support is not 100% complete yet.  We are working on it.

10) uClibc's math library only supports long double as inlines, and even
then the long double support is quite limited.

11) uClibc's libcrypt does not support the reentrant crypt_r, setkey_r and
encrypt_r, since these are not required by SuSv3.

12) uClibc does not implement wordexp()


13) uClibc directly uses the kernel types to define most opaque data types.

14) uClibc directly uses the linux kernel's arch specific 'stuct stat'.

15) Add other things here as they come up......



******************************  Manuel's Notes  ******************************

Some general comments...

The intended target for all my uClibc code is ANSI/ISO C99 and SUSv3
compliance.  While some glibc extensions are present, many will eventually
be configurable.  Also, even when present, the glibc-like extensions may
differ slightly or be more restrictive than the native glibc counterparts.
They are primarily meant to be porting _aides_ and not necessarily
drop-in replacements.

{'fraction_non_alphanumeric': 0.0579127586720262, 'fraction_numerical': 0.01012356706863183, 'mean_word_length': 4.470684039087948, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '4106533', 'n_tokens_mistral': 1881, 'n_tokens_neox': 1791, 'n_words': 1023}