Re: Bounds Checking

From: Ari Heitner (aheitnerat_private)
Date: Tue Jul 21 1998 - 06:13:50 PDT

  • Next message: Steven M. Bellovin: "Re: New Java Security Flaw Found"

    You know the real reason God kicked Adam & Eve Consulting Associates LLC
    off the Eden project, dontcha? Adam & Eve wanted to audit everything and
    redo Creation in java.
    
    I'm going to get shot for saying this, but this is clearly a case where
    the flexability of C++ to add extensions to itself (thus "a language for
    writing languages") would come in handy. Writing secure programs? Write
    yourself a secure array class. I know, the unix world depends on C, not
    C++. I know on many systems a good C++ compiler is not available. However,
    coming from a background of writing computer games, I still believe in
    performance. Do _anything_ in a nice tight loop 400k times and speed
    becomes an issue. Ada and java and what-have-you just don't cut it.
    
    Realistically tho you can implement some of the more basic parts of
    object-oriented design in C. It's painful to live without conveniences
    like templates, but most 98% of buffer overrun problems occur in arrays of
    chars. Using vaguely C++-like function names
    (i.e. array_setvalue(array myarray,long index,char value) instead of
    array.setvalue(...)) you could implement yourself some nice safe arrays. I
    think this is much better than having the bounds checker built into the
    compiler do something annoying and not under your control (by Murphy, the
    opposite of what you'd like it to do) when bounds are overrun. It's secure
    if the program quits when you pass it 10k 'X' characters looking for a
    crash, but it's _elegant_ if the program deals with the error internally
    rather than relying on the compiler's bounds checking code. It also gives
    power to the programmer, which is the point of not using visual basic :).
    
    Ari Heitner
    ----------
    aheitnerat_private
    tel: 703/5733512
    fax: 703/5731447
    



    This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:06:48 PDT