🚀 go-pugleaf

In article <4fvmmm$o5j@meaddata.lexis-nexis.com> christw@meaddata.com (Christopher C. Wood) writes:
>In article <danpop.824303108@rscernix>, danpop@mail.cern.ch (Dan Pop) writes:
>|> In <4fqdta$rhh@meaddata.lexis-nexis.com> christw@meaddata.com (Christopher C. Wood) writes:
>
>|> >In article <9602121654.AA02634@ues5.cern.ch>, Dan Pop <Dan.Pop@cern.ch> writes:
>
>|> >What is the non-trivial method to convert an integer into an ASCII
>|> >representation of its value?  All I need is code that will run on
>|> >Solaris (2.3) and HPUX 9. 
>
>|> Why do you want to do it in a non-trivial way?  What's wrong with the
>|> trivial method: sprintf(buff, "%d", intval)?
>
>Linking in a 15K library when all I need is a 50-byte subroutine.
>
>Laziness like you suggest leads to code bloat.
>
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!

Is it 8bit,16,24,32,36,64?
Is it(if 16 bit) abcd, badc,cdab, or dcba?
Is it binary or BCD or what?
Is it ones complement or two?
If it is Floating point, then WHICH format?  DEC VAX for example has, as I
recall, FIVE!!!!!!

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

Steve

BTW little endian and big endian simply aren't discriptive enough!