🚀 go-pugleaf

In article <4g2i5q$dj7@meaddata.lexis-nexis.com> christw@meaddata.com
(Christopher C. Wood) writes:

> In article <stephenkDMuGux.Iot@netcom.com>, stephenk@netcom.com
> (Stephen Knilans) writes:

> |> If you write code to directly convert a binary number to a human
> |> readable version, and find that it won't work the same on all
> |> processors, this is NOT the fault of C!!!!!!!!!!!  It is because
> |> MANY processors are different!

> |> The libraries are there for a REASON!  There are possibly HUNDREDS
> |> of number formats, and it is very difficult to provide for all.

> Look, I've shown a bunch of things with this thread.  _none_ of the
> respondants pointed out that there is a "standard" library call to do
> this: itoa().  As documented in K&R (I'd cite page numbers, but I
> don't have it at this desk.)  As _assumed_ in Stroustrup, 2nd ed.
> Guess what?  This "standard" library call, in actual practice, isn't
> standard.  Each platform has its own version.  One version is even
> wrong in the manufacturers on-line documentation.  Is this a fault
> with the "Standard" for C or C++ libraries?  Or just the
> implementations.  You tell me.

The "documentation" in K&R is on page 64 (2nd ed.), where they show
how to write it.  They never claim it is part of any library.  The
code that they provide is system-independent.  (It does depend on one
function that they wrote earlier in the book, reverse() which reverses
a string in place.)  It is not even library-dependent.

Also, in regard to your claim that linking in sprintf links in the
full stdio library, well, atoi (and relatives) links in the full
stdlib library.  Unless, of course, you have an intelligent linker
which only brings in symbols that are actually referenced.

Just a Thought,
Jim Trigg