I'm cautiously optimistic that Rust will improve the situation.

What matters is the interface, not the implementation. You can have a library implemented in C++ but with a pure 'extern "C"' interface, and it'll be as easy to use as a library implemented in C.

No, the real problem with writing a library in C++ is the "which C++ runtime" question. The C++ ABI is not a solid as the C ABI, and there is more than one C++ runtime. Loading more than one C++ runtime on the same process, with the common ELF linking rules, is not a good idea.

(On Win32, there is more than one C runtime, but it's less of a problem because its symbol resolution rules make it easy to have several incompatible runtimes in the same process without many issues.)

But I believe the reason C is used instead of C++ is complexity and historical reasons. Many libraries were first written back when C++ compilers were not as good, so they used C by default; and C is simpler to write and understand.

This is probably the best perspective to start from, even though it is depressing for those who get into computers for the mathematical perfection. You get better by accepting risk and then managing it, rather than trying to eliminate risk using math or by expecting perfection.

How would computing and networking look if we just accepted the risk and rolled back all of the encryption, signature verification, complex policy tagging and enforcement and just had some very basic permissions. It's like ChaosMonkey, how you design complex systems to be robust by expecting failure rather than treating it as exceptional. Would we develop more robust audit features or flexibility to roll back malicious changes rather than trying to prevent them. Malicious activity on computer networks is ultimately caused by people, and as a species we've been dealing with malicious people since forever, how could those coping mechanisms be translated into the computer network?

Could we handle the problems that encryption and the like are intended to solve in meatspace rather than with technology in computerspace?

Put those two together, and you can programmatically fail malloc at any point in your program, more or less.

I've done this, but to profile memory usage, not for failure testing. For allocation failure testing I usually just interpose malloc, randomly return failure, and re-run for a very long time.

(Though, I grant, that is a higher level architectural problem then low-level code, but the theory applies)

I do think though there are at least some techniques that might reduce the rate at which certain security sensitive errors are introduced, and the impact of bugs. In particular, state transitions could be specified in a more restricted and easier to verify way, e.g. as states and transitions in an FSM, rather than hand-written branches acting directly on state. I've this blog on it:

http://paul.jakma.org/2013/12/05/code-and-error-handling-...

An FSM is easier to analyse than full-blown code. E.g. it is guaranteed you can detect unreachable states. The states and transitions can be abstracted out from the rest of the code, and specified in a more concise way, making it easier for humans to analyse too. Idempotent error states are easier to specify, making it easier and safer for /other/ code to interact with that code.

It's no magic bullet, of course, but it can help. It applies to a variety of languages.

There's an unfortunate lack of general purpose FSM tools for C though, last I checked, to actually do the checking. The ones I know about seem to be heavily orientated to string-parsing FSMs.

Not relevant to the SSL bugs (Which were logical), but for network parsing code generally the code doing the syntactical parsing of external input should also use a bounded-buffer abstraction to access that external input. That some languages don't have built-in memory-access checking is not a barrier to implementing your own checking-abstractions!

The issue isn't really C, but programming practice that under-values using layers of formal abstractions, as well as testing. None of this is new.

PS: I'd love to hear about other abstractions that could be applied to help systematically catch errors. ???

Maybe not, but destructors still make it easier to get cleanup correct, whether exiting a function by returning or by throwing an exception, and it's that kind of "must be performed before returning" cleanup that the "goto cleanup" and "goto fail" jumps are performing.

> Having a function called check_if_ca() throw an exception from the checks it's doing, would be like having a string comparison function that threw if the strings weren't equal, or a character classification function throwing if the character you passed it didn't fall into the right category. It's just not the way you ought to handle that sort of "error".

As you implied by putting "error" in quotes, neither the strcmp case nor isdigit case is an error at all.

> You can very well argue that having strcmp() return 0 for a match, and non-0 for failure,

The results "compares less than" and "compares greater than" are not "failure", they're two of the three valid results from strcmp. None of those results indicates an error. Similarly for isdigit, a false result is not an error.

> But (IMNSHO) changing them to throw on failure would be an even bigger mistake.

Well yes, obviously. An exception means something went wrong, not "the answer to your question is no". Using an exception to answer whether a character is a digit or not would be dumb. The result of strcmp is not "pass" or "fail" so throwing an exception makes no sense at all. Throwing an exception might make sense if the argument to isdigit is not representable as unsigned char, or if either argument to strcmp is null (and indeed C++ implementations are already allowed to do that because such arguments produce undefined behaviour).

sslChecks :: [CertChain -> Cert -> Reader SslContext (Maybe String)]
sslChecks = [validCert, acceptableAlgorithm, trustedChain, ...]

sslCheck :: CertChain -> Cert -> Reader SslContext (Maybe String)
sslCheck chain cert = (liftM mconcat . sequence) . map ($ cert) . map ($ chain) $ sslChecks

where a failure just bails out of the code at the end (the Reader monad stores the options any checks might care about). No style, error checking, boilerplate, or whatever to worry about. Just write a check, put it in the right place in the lift of checks to make and return an error string if necessary.

I see where are you coming from, but I cannot agree. strcmp() is not for checking equality, even if you can use it for that. It's an order operator, because the sign of the return value matters, so the return value cannot be a boolean.

In any case the _only_ way to remove error paths -either implicit or explicit- from your code is to create complete functions (http://en.wikipedia.org/wiki/Functional_completeness) whenever possible.

Even if anyone would want to do that for whatever reason, then they would simply not activate the check for actual boolean conditions.

While everyone not doing something like that would have additional type safety, either as warning but ideally as an error.

Thanks a lot!

Looks like they were programming in Perl 6 before Perl 6 even existed :)

> I wonder if this is true?

In addition to the culture of limited testing you alluded to, I think there are some language issues here as well. C will let you do pretty much anything in a function, which is one of its strong points in certain kinds of code. The flip side to this, however, is that it means you have to _test_ for pretty much anything. You got an enum value... how do you know it's actually one of the defined values, when anyone can pass in whatever integer value they want? You got a pointer... how do you know that it points to valid memory of the correct type? How do you test for the absence of unexpected side-effects? Does the result depend on inputs other than the parameters?

In certain other languages (like Haskell) the type system ensures that thing like out-of-range enums, invalid pointers, and undeclared side-effects simply can't happen unless you go out of your way to bypass the system (e.g. with something like unsafeCoerce or unsafePerformIO, which set off major warning flags). If a function is declared with type "MyEnum -> MyDataStructure -> String" then you only need to test it on valid enum values and data structures; the result is guaranteed to be a well-formed string dependent only on the two parameters, and there won't be any side-effects. This makes testing far simpler even before you consider libraries like QuickCheck.