🚀 go-pugleaf

In article <nevin-1902962104170001@150.135.1.79>,
Nevin ":-]" Liber <nevin@CS.Arizona.EDU> wrote:
>In article <danpop.824475697@rscernix>, danpop@mail.cern.ch (Dan Pop) wrote:
>
>> >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?).
>
>Of course, you didn't even know this was an issue until I pointed it out. 
>I notice that you don't post the code to do that calculation here.  Also,
>it is lousy programming to incur a run-time cost for something that is a
>known quantity at compile time.

Right.  But I've already posted the code that does this at compile
time (the expression evaluates to a compile-time constant), so Dan
doesn't need to post it.  :-)

>> It's easy to get it right and 100% portable for any C programmer with half
>> a clue.
>
>Well, I guess you don't have half a clue, since you *didn't* post the code
>that gets this 100% correct and portable.  A bunch of handwaving with your
>malloc comment just doesn't cut it.  If it's so darn trivial to compute
>the maximum size of buff, why don't you provide a compile-time expression
>that evaluates to it?

Errm...because someone else already did?

>  Another thing you failed to mention (I know, you're
>gonna claim that it is so trivial that it doesn't need mentioning to cover
>up the fact that you didn't even consider it) is that the maximum size of
>buff is also dependent on the number of bits per byte.  

Already taken care of, in the second iteration, anyway.

>Personally, I'm
>not sure C is rich enough to support this, since it requires being able to
>take the log of a number at compile time.  

As far as I know (but I haven't been able to verify this), CHAR_BIT is
an ANSI-defined constant and therefore portable.  And since we're
talking about portable ANSI code here...

>But, since you claim to know
>better, why don't you post this compile-time expression for us? 

Sigh...guess I should post it again in case you missed it:


/* Pick up CHAR_BIT in <limits.h> */
#include <limits.h>
#include <stdlib.h>

/*
 * 31/100 >= log(2) == number of base 10 digits required to store a binary
 * digit.
 */
#define BUFLEN ((sizeof(int) + 1) * CHAR_BIT * 31 / 100 + 3)

char *itoa ( int x )
{
    char *buf, *p, *p2;
    int negative = 0;
    static char nums[] = { '0', '1', '2', '3', '4', '5', '6', '7',
    '8', '9' };

    if ( ! ( buf = malloc(BUFLEN) ) )
        return buf;
    p = buf + BUFLEN - 1;
    if ( x < 0 )
    {
        x = -x;
        negative = 1;
    }
    *p-- = 0;
    do
        *p-- = nums[x % 10];
    while ( x /= 10 );
    if ( negative )
        *p = '-';
    else
        p++;
    if ( p != buf )
    {
        p2 = buf;
        do
            *p2++ = *p;
        while ( *p++ )
    }
    return buf;
}


>The hard part about writing portable code isn't the complexity of the
>final result; it's making sure that you've taken all the issues into
>account, because your compiler won't tell you when you haven't.

This isn't limited to portability...it's true of software engineering
in general.  It's *always* an exercise in making sure that you've
taken everything into account.


-- 
Kevin Brown                                     kevin@frobozz.sccsi.com
This is your .signature virus: < begin 644 .signature (9V]T8VAA(0K0z end >
            This is your .signature virus on drugs: <>
                        Any questions?