🚀 go-pugleaf

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

>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.

Even if the expression can be evaluated at compile time, it is _not_ an
integer constant expression (as defined by the ANSI standard), hence it
cannot be used as the size of a statically allocated array.  I could
try to approximate log(10)/log(2) by the ratio of two integers, but
this would be only an approximation, not the real thing.

>> 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? 

Here it is: CHAR_BIT * sizeof(int) * log(2) / log(10) + 3, converted to
an integer type, of course.  Replace 2 and 10 by 2.0 and 10.0 if you
don't have an ANSI C compiler.

The best attempt to get a constant expression usable to size an array
would be:

(CHAR_BIT * sizeof(int) * 6931471) / 23025850 + 3

Unfortunatelly, it's considerably more obfuscated than the original version 
(three magical constants are a bit too much).

>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)

Wow, since when are you a mind reader?

>is that the maximum size of
>buff is also dependent on the number of bits per byte.

Don't be idiot.  The number of bits per byte has to be used in order to
compute the number of bits of the int type and this computation is 
unavoidable when computing the size of the buffer.  It's obvious that
the final result of an expression depends on all the factors involved in
that expression.  You don't need a PhD in math to realize this.

>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.

You can't do this in a constant expression.  You have to either use the
workaround above (which is overflow-proof, BTW) or use the exact expression
and malloc().

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

Done.

>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 is precisely what makes portable programming interesting.

Dan (whose name can be seen in the "Acknowledgements" section of the
     comp.lang.c FAQ :-)
--
Dan Pop
CERN, CN Division
Email: danpop@mail.cern.ch 
Mail:  CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland