> 1. Features that help avoid mistakes. Such features are valuable in
> all programming domains (not just security) and include things like
> strong typing, automatic memory management, few or no automatic type
> conversions. [...]
> 2. Features that help to make the program secure and robust for all
> inputs (for example, to prevent buffer overflows). My preference
> here is for an automated tool to generate properties of the form "for
> all possible inputs to this module, this array index will be in bound
> at all times" and then generate the proof automatically (or point out
> the likely error).
I can't help thinking that this is all going to just push the errors up
a level.
When moving from machine code to assembly code, certain errors were
more or less eliminated ("oops, I forgot to update that branch
displacement to account for the extra instruction in between").
When moving from assembly code to C code, certain errors were more or
less eliminated ("oops, I forgot to allocate stack space for that new
local variable").
When moving from C code to, say, Java code, certain errors are more or
less eliminated ("oops, I forgot to update the malloc argument to
account for the extra characters").
But you'll note that in each case, errors remain - errors still occur
at the level of abstraction provided by the language in question.
(Also, as the software responsible for translating the human-written
code into machine-executable code grows in complexity, its bug level
rises correspondingly.)
This is not to say that moving up levels is worthless. But it sounds
to me as though everyone in this discussion is stuck in some kind of
mindset like "if we can just eliminate $CLASS_OF_ERROR, we'll have a
safe and secure programming language". We won't; we'll just have one
where the unsafe and insecure errors are at a higher level.
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML [EMAIL PROTECTED]
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
