🚀 go-pugleaf

In <nevin-1502960049080001@150.135.1.79> nevin@CS.Arizona.EDU (Nevin ":-]" Liber) writes:

>In article <danpop.824303108@rscernix>, danpop@mail.cern.ch (Dan Pop) wrote:
>
>> 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:
>> >
>> >|> It's damn easy to write non-trivial portable ANSI C.  All you have to do
>> >|> is not to rely on platform-specific features (size of certain types,
>> >|> byte sex, etc) and functions.  
>
>> >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)?
>
>It's not portable yet.  What is the minimum size that the buffer that buff
>points to should be in order to store an int for any possible (not
>necessarily just existing today, but anything that conforms to the current
>standard) ANSI C implementation?
>
>Like I said, this stuff isn't that easy to get right and 100% portable.

It's definitely portable, because buff doesn't have to be statically
allocated.  It's trivial to compute the maximum size of buff, based on
sizeof(int) and allocate the right number of bytes for buff (ever heard
of the malloc thingie?).

It's easy to get it right and 100% portable for any C programmer with half
a clue.

Dan
--
Dan Pop
CERN, CN Division
Email: danpop@mail.cern.ch 
Mail:  CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland