minor doc update

1 files changed, 16 insertions, 12 deletions

diff --git a/docs/Glibc_vs_uClibc_Differences.txt b/docs/Glibc_vs_uClibc_Differences.txt
index 56d955693..4ed24639e 100644
--- a/docs/Glibc_vs_uClibc_Differences.txt
+++ b/docs/Glibc_vs_uClibc_Differences.txt
@@ -12,7 +12,7 @@ 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.  
+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
@@ -39,7 +39,7 @@ functionality from uClibc is not a great loss.
 support various methods of authentication and DNS resolution.  uClibc only
 supports flat password files and shadow password files for storing
 authentication information.  If you need something more complex than this,
-you can compile and install pam. 
+you can compile and install pam.
 
 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
@@ -48,26 +48,30 @@ 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
+is an evil abomination and should not be used.  These days, using ldap is much
 more effective mechanism for doing the same thing.  uClibc provides a stub
 libnsl, but has no actual 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).
+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.
+then the long double support is quite limited.  Also, very few of the
+float math functions are implemented.  Stick with double and you should
+be just fine.
 
 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 directly uses the kernel types to define most opaque data types.
+12) uClibc directly uses kernel types to define most opaque data types.
 
 13) uClibc directly uses the linux kernel's arch specific 'stuct stat'.
 
+14) uClibc's librt library currently lacks all aio routines, all clock
+    routines, and all shm routines (only the timer routines and the mq
+    routines are implemented).
+
 <other things as we notice them>
 
 
@@ -189,17 +193,17 @@ requires that you rebuild everything with profiling support.  There is both a
 size and performance penalty to profiling your applications this way, as well
 as Heisenberg effects, where the act of measuring changes what is measured.
 
-These exist a number of less invasive alternatives that do not require your to
+There exist a number of less invasive alternatives that do not require you to
 specially instrument your application, and recompile and relink everything.
 
+The OProfile system-wide profiler is an excellent alternative:
+      http://oprofile.sourceforge.net/
+
 Many people have had good results using the combination of Valgrind
 to generate profiling information and KCachegrind for analysis:
       http://developer.kde.org/~sewardj/
       http://kcachegrind.sourceforge.net/
 
-The OProfile system-wide profiler is another alternative:
-      http://oprofile.sourceforge.net/
-
 Prospect is another alternative based on OProfile:
       http://prospect.sourceforge.net/