[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