[patch] cxx.uclibc website typos

Bernhard Fischer rep.nop at aon.at
Sat Apr 1 10:38:07 UTC 2006


Hi Garrett,

Attached is a patchlet which corrects some typos i discovered while
reading cxx.uclibc.org.

I'm not sure if you mean "mock" instead of "much" in the last paragraph
of the FAQ, so i left that one alone:
"If you are truely sadistic, then I am in need of somebody to much around
with the internals of"

Please apply.
-------------- next part --------------
diff -rup cxx.uclibc.org.oorig/about.html cxx.uclibc.org/about.html
--- cxx.uclibc.org.oorig/about.html	2005-12-10 17:52:59.000000000 -0800
+++ cxx.uclibc.org/about.html	2006-04-01 02:04:08.000000000 -0800
@@ -23,7 +23,7 @@
 <div style="float: left;">
 	<H3>About</H3>
 	<P>uClibc++ is a C++ standard library targeted towards the embedded systems/software market.  As such it may
-		puposefully lack features which you might normally expect to find in a full fledged C++ 
+		purposefully lack features which you might normally expect to find in a full fledged C++ 
 		standard library.  The library will focus on space savings as opposed to performance.
 
 	<P>The author of uClibc++ is Garrett Kajmowicz, who is employed as a software engineer with <A 
diff -rup cxx.uclibc.org.oorig/faq.html cxx.uclibc.org/faq.html
--- cxx.uclibc.org.oorig/faq.html	2005-12-10 17:51:32.000000000 -0800
+++ cxx.uclibc.org/faq.html	2006-04-01 02:19:56.000000000 -0800
@@ -34,7 +34,7 @@
 
 	<P><B>Why doesn't your library support feature X</B>
 	<P>There are two possible reasons.  The first is that I simply haven't gotten around to writing it.  How about
-		you write a conformence test for the feature and send it to me, and I'll implement the feature when I
+		you write a conformance test for the feature and send it to me, and I'll implement the feature when I
 		get around to it.  The second is that I have decided that this feature is inappropriate for an embedded
 		software/C++ library.  As such, I have no plans to implement that feature at all (such as locales)
 
@@ -55,30 +55,29 @@
 		</ul>
 	<br>In my view, any one of the above is a good enough reason to use C++ over C (or EC++).  As such, stripping
 		them out does not sit well with me.  uClibc++ is designed to be used with a complete C++ compiler and
-		a C standard library.  Few C library features are actualy required, but it is just easier to say that
+		a C standard library.  Few C library features are actually required, but it is just easier to say that
 		they are.
 
 	<P><B>What are the differences between uClibc++ and a typical C++ library implementation?</B>
-	<P>Firstly, all of the code was designed with size in mind, both code and memory.  This meens that 
+	<P>Firstly, all of the code was designed with size in mind, both code and memory.  This means that 
 		some design choices were made in order to conserve memory which may reduce performance.
 		The main differences are:
 		<ul>
 			<li>No locale support at the C++ level</li>
 			<li>Map currently uses a deque instead of a tree structure</li>
 			<li>I/OStream library does not call locales</li>
-			<li></li>
 		</ul>
 	<P>Most of the differences are trivial for all but the most bizzare cases.  Let me know if you
-		tun into any problems.
+		run into any problems.
 
 	<P><B>Why use a deque for map?</B>
-	<P>A deque needs only 3 pointers and a size parameters (essentially 4 integers) to manage itself.  Compare this
+	<P>A deque needs only 3 pointers and a size parameter (essentially 4 integers) to manage itself.  Compare this
 		with at least 2 pointers per item for a tree.  After two items, the memory overhead of the map already
 		outweighs that of the deque.  Also, deque lookups may be faster as moving to the next level in the
 		search does not require indirection.  On the down side, a deque does not resize cleanly like a map does.
 		It will use more memory than needed in buffering, and will occasionally need to copy all of the elements
 		to a new container for more free space.  Inserts also execute in O(n) time instead of O(log(n)) time on a
-		deque unless they are to be added to the front or back of the deque, at whic point they are inserted in 
+		deque unless they are to be added to the front or back of the deque, at which point they are inserted in 
 		O(1)+ time. Lookups and updates are O(log(n)) on both systems.  In the end, I thought that the memory
 		usage of the system outweighed the performance issues involved.
 
@@ -88,12 +87,12 @@
 		about 100k when compiled with no optimization.  When compiled with size optimization it drops to around 76k.
 		For best results, try it on your system.
 
-	<P><B>Is the code ISO complient?</B>
-	<P>I believe that all of the library code is IOS complient in terms of syntax.  Since it is not complete, it is 
-		not complient in terms of content.
+	<P><B>Is the code ISO compliant?</B>
+	<P>I believe that all of the library code is ISO compliant in terms of syntax.  Since it is not complete, it is 
+		not compliant in terms of content.
 
 	<P><B>What compilers does uClibc++ work with?</B>
-	<P>The library is written with and for GNU G++ version > 3.3.0.  I am developping on a system using 3.3.3.
+	<P>The library is written with and for GNU G++ version > 3.3.0.  I am developing on a system using 3.3.3.
 		One of the biggest problems with C++ is the ABI used.  I don't feel very comfortable implementing it
 		since much of the implementation is done inside the compiler.  As such, the ABI code is copied from 
 		GNU G++ headers or libraries, as appropriate.  You are free to try and use a different C++ compiler.
@@ -101,18 +100,18 @@
 
 	<P><B>Why don't you support locales?</B>
 	<P>Locales are a really neat feature, but they are very large.  My preliminary support for them was about 50k
-		before I chopped it out of the project. And at that point my implemenation didn't do anything useful.
+		before I chopped it out of the project. And at that point my implementation didn't do anything useful.
 		My rational for this was fairly straightforward:  almost no embedded system is going to need locales.
 		If you are using a GUI toolkit, you most likely have better features for locale handling than will
 		be offered by the C++ standard.  If you are using files on an embedded system (say for logging), the
-		character used as a decimal marker is pretty much irrelevent.  It comes in handy only when you are
+		character used as a decimal marker is pretty much irrelevant.  It comes in handy only when you are
 		looking at doing output to the console, and an embedded system is more likely to use custom functions
 		for output than the console.  Just face it:  how often do you explicitly use locales when programming?
 		Probably not often.
 
 	<P><B>How do I use the library?</B>
 	<P>The library builds a wrapper script, g++-uc, which sets all of the required library calls to effectively
-		use the library.  Though it doesn't cover all possabilities, it is sufficient to be able to compile
+		use the library.  Though it doesn't cover all possibilities, it is sufficient to be able to compile
 		large applications like KDE.  Simply use the wrapper script anywhere you would call g++ directly,
 		or override the CXX environment variable if calling scripts and compile away!
 
@@ -121,7 +120,7 @@
 		works, let me know.  If not, also let me know.  Ideally, track the bug down to a particular cause and
 		submit a minimal example case which works under GNU libstdc++ but not uClibc++.  Then see if it falls
 		under one of the categories above.  Ex, if the problem is a lack of locale support, I'm not likely to
-		care.  However, if it is an iostream issue than I will endevor to resolve the problem as quickly as
+		care.  However, if it is an iostream issue than I will endeavor to resolve the problem as quickly as
 		possible.
 	<P>If you would like to become involved directly with the code then I am looking for implementations of a
 		comprehensive test suite.  This will discover more and more bugs, making the library better and
diff -rup cxx.uclibc.org.oorig/status.html cxx.uclibc.org/status.html
--- cxx.uclibc.org.oorig/status.html	2005-12-10 17:37:49.000000000 -0800
+++ cxx.uclibc.org/status.html	2006-04-01 02:20:48.000000000 -0800
@@ -22,8 +22,8 @@
 
 <div>
 	<H3>Status</H3>
-	<P>There are a number of components in the C++ library which are continually being developped.
-		Here are is status of these elements.
+	<P>There are a number of components in the C++ library which are continually being developed.
+		Here is the status of these elements.
 
 	<table><tr><th>Component</th><th>Status</th></tr>
 	<tr><td>Exceptions</td><td>Done.  Core code from the GNU library.</td></tr>


More information about the uClibc mailing list