This is a straw-man. A bug in the destructor would lead to resource leaks and to eventual program failure. "Slightly" different from a complete and silent failure to perform a critical security task.
> Bugs happen, in any language.
Another straw-man. Some languages are more conducive to certain types of bugs. See PHP for example.
> You could rewrite it in prolog for all I care, it doesn't address this core issue.
The core issue is bad software engineering. If you look at the code more closely, it doesn't even use a consistent convention for signaling failure. The code looks something like
if (ret < 0) { ... goto fail; }
and at 'fail' label you find `ret = 0` followed by freeing resources and returning ret to the caller.
The bug wouldn't be there either if they just settled on using the POSIX convention of negative return value meaning failure. But no.., they have to translate it to a pseudo-boolean stored in an int.
I wasn't planting a straw man, I was just pointing out that it's possible to write subtly broken C++ (or prolog, or ADA, or whatever) code as well.
Maybe it would make it harder to introduce this kind of bug (after all, goto error handling could be considered a hack because C lacks proper exceptions) but no language is bug-proof by design. If you're writing security-sensitive code you should have complete code coverage with tests. If you have that you could implement the library in assembly for all I care.
I'm not attempting to bash C++, it's a language I use from time to time. And I agree that RAII is a convenient patter that I often yearn for in C. It's just that in my opinion in this case (and in the "goto fail" bug of late) that's not the core of the issue.
This is a straw-man. A bug in the destructor would lead to resource leaks and to eventual program failure. "Slightly" different from a complete and silent failure to perform a critical security task.
> Bugs happen, in any language.
Another straw-man. Some languages are more conducive to certain types of bugs. See PHP for example.
> You could rewrite it in prolog for all I care, it doesn't address this core issue.
The core issue is bad software engineering. If you look at the code more closely, it doesn't even use a consistent convention for signaling failure. The code looks something like
and at 'fail' label you find `ret = 0` followed by freeing resources and returning ret to the caller.The bug wouldn't be there either if they just settled on using the POSIX convention of negative return value meaning failure. But no.., they have to translate it to a pseudo-boolean stored in an int.