Re: compilation of ms crypto api program

From: Ernst Lippe (ernstl-at-planet-dot-nl_at_ignore.this)
Date: 06/22/03 

Date: Sun, 22 Jun 2003 13:45:20 +0200

On Sat, 21 Jun 2003 22:52:13 +0000, Henrick Hellström wrote:

> Russ Lyttle wrote:
>> Henrick Hellström wrote:
>>>Java is a terrible language for teaching. People who start off with Java
>>>or Basic tend to do radically stupid things when encountered with a
>>>language that supports pointers.
>>>
>>
>> People tend to do radically stupid things with pointers in any case.
>
> No, not in *any* case. Pointers in Standard Pascal were fairly straight
> forward, and couldn't really be used in any stupid way what-so-ever. If
> you were going to use a string array with 255 elemenst, you had to
> declare a type TMyCharArray = array [1..255] of Char and use that,
> either as a pointer type PMyCharArray = ^TMyCharArray with variables
> allocated with New or with static variables allocated on the stack.
> Using a pointer in an unappropriate manner would simply result in a
> compile time error.
>
> Compare this with the C language where there is no real distinction
> between a pointer to a single uint8 and a pointer to an array of uint8
> (*Char).

With all Pascal compiler that I have seen, even the first that
was developed by Wirth, it was possible to circumvent this by
using variants. Because in the original Pascal definition the
length of an array was part of its type this trick was commonly
used in many programs. But of course this breaks array bounds
checking. In this respect Java is much safer because it is
simply impossible to circumvent the array bound checks.

>>>Nah, give them Pascal and teach them to implement good old fashioned
>>>linked lists third week in class. ;)
>>
>> Not a bad idea. Do you have any idea how many recent graduates can't write a
>> linked list?
>> Now, back to Crypto...
>
> This is crypto at least in-so-far buffer overruns are concerned. I think
> it might be relevant to discuss ways to promote safe programming. I
> don't believe restricting programmers to work with e.g. Java or .NET
> managed code is the right way to go, since I really don't see any kind
> of run time environment which is sufficiently efficient to do without
> hard type casts and which has secure garbage collection and secure
> memory management, and consequently doesn't need the equivalent of e.g.
> the C++ address (&) operator.

It always amazes me how obsessed some crypto people are with
performance. Perhaps it is a bit naive, but I would expect that they
should be far more interested in security. Buffer overflows are
probably the most common source of security problems in software. They
can be completely eliminated by using an appropriate language.

Also, I believe that you are exaggerating the performance problems of
Java. First of all, interpreted languages in general have a constant
overhead compared with compiled languages. When your hardware becomes
faster, and it still does, this constant factor gets less
important. In many programs IO is the bottle-neck and that is not
dependent on your programming language. Second, modern JIT (Just in
Time) compilers can do very important optimizations, in many cases
there is no real difference for the end-user between Java programs and
those written in compiled languages.

greetings,

Ernst Lippe

Relevant Pages

  • Re: modifying array access syntax
    ... So a call to a string (or an array) indexes into the table by the string or array typetag to find the function to call. ... I haven't done it yet, but in cases where I can prove what type that first element in the call is going to be, I could compile so as to skip the lookup and open-code it (hmm, assuming I leave "typecall" functions constant/ global/ immutable, like language primitives ... ... libraries and doing hardware I/O and such, ...
    (comp.lang.lisp)
  • Re: pointers?
    ... There's absolutely nothing abstract in pointers. ... Take the C array: if you write ... To the assembly language programmers who were the first generation adopters of C, this mental mapping was very tight. ... Forth gained the most traction on machines like the IBM 1130 and the Data General Nova. ...
    (comp.lang.forth)
  • Re: pointers?
    ... There's absolutely nothing abstract in pointers. ... Take the C array: if you write ... more abstract language later, 70% would get it. ... quite obvious that this is a language close to the hardware, ...
    (comp.lang.forth)
  • Re: The coming death of all RISC chips.
    ... All you really need to be able to do is test them for equality/inequality (and to null if you can't define a null pointer to test for equality. ... It is things like doing arithmetic on pointers that causes many of the potential alias problems. ... Pascal as defined in the original Wirth report was defined to be a toy/teaching language. ... If you can compile to C you can compile to object code. ...
    (comp.arch)
  • Re: Best Ref-counting algorithms?
    ... The programming language is designed so that most data ... a:=0 #now the array magically disappears and a is an int ... It doesn't work well however when the language allows *explicit* pointers: ... because explicit pointers aren't used so much, and when they are they are ...
    (comp.compilers)