[Cryptography] how reliably do audits spot backdoors?

James A. Donald jamesd at echeque.com
Sat Dec 28 16:21:47 EST 2013


 >>> I do it all in Java.  Once, when I did a port from Java to various
 >>> languages, it took 5 times longer to get it into C as opposed to
 >>> various OO languages (PHP, Perl).

 > On Dec 28, 2013, at 5:04 AM, James A. Donald wrote:
 >> Transating to C, you have to add your own memory management code,
 >> which is a large part of any C program, hence the much longer C
 >> translation times.
 >>
 >> Modern C++ has tools that substantially automate memory
 >> management and  type management, but you still have to think about
 >> memory management, while Java does it all for you.

On 2013-12-29 05:21, Jerry Leichter wrote:
 > It really depends on what you're doing.  Java only *appears* to do
 > it all for you; while you can't get the traditional memory leak
 > (memory to which no accessible pointers exist), you can easily build
 > up piles of guck that's pointed to by hash table entries you forgot
 > to clean up, for example.  And the GC doesn't help you with
 > non-memory resources.  This is where destructors, if used carefully,
 > can really pay off in C++:  You can guarantee [...] the complete
 > cradle-to-grave semantics of types you  define.  You can't do that
 > in Java - you're left telling users they  *must* call close() before
 > they stop using function, which they  forget to do

If you translate from Java to C++, then chances are you are not fully
using the C++ memory management and resource management features - you
are still hoping that guy  who called your code  called "close".



More information about the cryptography mailing list