
Writing Your Last For-Loop - Beautiful Code - nickb
http://beautifulcode.oreillynet.com/2007/10/writing_your_last_forloop.php
======
cperciva
Before criticizing a language, understand it. In this case, the author can't
even write a for loop correctly:

    
    
     for(int n = 0; n < size; ++n) 
          sum += elements [n];
    

Leaving aside the stylistic question of declaring variables in the middle of a
for statement, and trusting that the author knows that the variable _sum_ will
never overflow and (if he's dealing with floating-point values) that rounding
errors won't matter, the code should still be

    
    
     for(size_t n = 0; n < size; ++n) 
         sum += elements [n];
    

An index to an array should always be declared as _size_t_ , not as _int_.
Otherwise really bad things can happen on systems where size_t is 64 bits but
int is 32 bits.

EDIT: Before someone accuses me of being overly pedantic: I've lost count of
how many security issues I've fixed which have existed because someone used
_int_ where they meant _size_t_ , but it's at least in the double-digits.

~~~
dfranke
Pedantically you're correct, but on what archictecture/compiler is (sizeof
int) != (sizeof size_t), and in what circumstances have you seen this become a
vulnerability? (I'm not trying to be argumentative here; I'm legitimately
curious.)

~~~
brl
I was going to argue against this too because using integers to index loops is
such a huge convention in C and then I realized that he's absolutely right.

On LP64, integers are 32 bits and size_t must be 64 bits (or you could
overflow it with otherwise legal code).

Even when integer and size_t are the same size, using an integer as an array
index is dangerous unless you make sure that it is not negative and can never
become negative.

Here's what easily exploitable code looks like:

void pad_ten(char *array, size_t length) {

    
    
        if(length < 10) {
            error();
            return;
        }
    
        for(int i = (length - 10); i < length; i++) {
            array[i] = doPadding();
        }

}

It's exploitable by either choosing a 'length' which becomes negative when
assigned to the integer or choosing a 64 bit 'length' which becomes an
entirely different (and incorrect) value when truncated to an integer.

------
edw519
Sorry, but I have the same reaction to any "programming language" argument, no
matter how eloquent: so what?

90% of your code should either be generated or copied from standard templates.
I've put over 2500 new programs into the library in the past couple of years,
yet I don't remember the last time I wrote a program from scratch.

I, too, am a stickler for details, but I let the compiler (or interpreter) do
its job. Why worry about nanoseconds when I have users running the asylum?

~~~
damon
I would argue a language that is eloquent, concise, and for lack of a fancier
word, pretty, is important. Language features change how you view and approach
a problem. I approach problems much differently in scheme given I have a macro
system than I would in C. I _think_ differently depending on the language.

And it's usually not about performance for me. I like code that looks good and
is dense.

