It's Time to Abandon Insecure Languages

[bear]

On Fri, 19 Jul 2002, Matthew Byng-Maddick wrote:

>Erm, what things do you think you can sacrifice? Pointer arithmetic,
>perhaps, except that it's a fairly fundamental part of C. The problems
>of buffer overflows are slightly screwy. Can you tell me, for example,
>what the length of s needs to be on
>a) a 32-bit machine
>b) a 64-bit machine
>and notice that most people don't even consider this.
>
>  sprintf(s,"%l",long_val);
>
>And, how big (on the same platforms) is:
>
>  sprintf(s,"%lf",double_val);
>
>You should also note that snprintf(3) is widely regarded as non-portable
>due to its non-existence on many platforms.

You may regard pointer arithmetic as fundamental, but I've
written lots of programs without using it.  As far as I'm concerned,
the only spot for numbers and pointers to mix directly is when
you need to set pointers at the absolute addresses of hardware
i/o ports and the OS provides no mechanism for discovering the
addresses of those ports.  Likewise, sprintf, in its raw or
traditional form, is one of the things you need to give up,
and which you should have given up already as part of good
programming practice.  It is badly designed.

It is possible to write a function that tells exactly
how many characters will be needed (at maximum) to carry
out a format command.  Any "good" definitions of sprintf ought
to use such a function, along with an access to the allocation
database maintained by malloc, or probably an enhanced malloc
that knows more about variable boundaries inside the stack,
to ensure that they are in fact writing into a buffer that's
big enough, and throw an appropriate error otherwise.

You've got a point about pointer arithmetic -- if it's really
widely used, there's just no hope for that body of code.  But
I still say that other than that, most of the problems with C
could be solved, transparently to most existing code, by an
appropriate refactoring of its malloc, I/O, and string libraries.

				Bear




---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com