Larry Kilgallen wrote... > So tell me what you think is easier in C/C++.
Well, just from a pure language POV, in comparing C++ with Java (sorry, not qualified to comment on Ada), there is one advantage to C/C++ over Java and that is in C++ I have a much higher level of confidence of doing things to clean up something when and object is destroyed. In C++, you can write a destructor to do this clean-up and you can predict exactly when the DTOR will execute. In Java, it is not so simple, even if all you want is to reclaim memory. You never really know when an object's finalize() method will be called (or even if it ever will except at exit) You are not supposed to rely on the timeliness of object finalization, nor are you really supposed to rely on finalizers to really do anything except for release memory. So why is this important? It's important because sometimes correctness and/or security depends on proper "clean-up". E.g., releasing a semaphore, overwriting memory (say for passwords or crypto keys), etc. Aside from that, the fact that Java doesn't allow you (native) access to all system calls can make things much more difficult. E.g., no direct access to fcntl(2) makes it impossible to use *nix mandatory file and/or record locking unless resorting to JNI. Or the fact that (AFAIK) Java doesn't support exclusive opens of a file or deal natively with sym links can cause security issues in certain situations. Of course these things are not so much the language per se as they are the supporting runtime environment which Sun wanted to ensure was portable across all the OSes that they support for Java. It's a trade-off and given their design goals, probably an appropriate one, but it does make doing certain tasks a bit more difficult to do securely. (Another example, Java supports nothing in its runtime environment to prevent an object from being paged out to swap--something that again would be desirable for things like crypto keys.) -kevin -- Kevin W. Wall 614.215.4788 Application Security Team / Qwest IT "The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents." -- Nathaniel Borenstein, co-creator of MIME _______________________________________________ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. _______________________________________________
