🚀 go-pugleaf

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.

> 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?  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.  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.  But, since you claim to know
better, why don't you post this compile-time expression for us? 

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.
-- 
        Nevin ":-)" Liber       nevin@CS.Arizona.EDU    (520) 293-2799