[Cryptography] GnuTLS -- time to look at the diff.

[Jerry Leichter]

On Mar 5, 2014, at 9:13 AM, Lodewijk andré de la porte <l at odewijk.nl> wrote:
> What's up with using GOTO in very secure applications? Isn't it wiser to use a functional programming -ish approach? IOW: Isn't this far harder to validate?
If you're talking about *formal* validation (i.e., program proving), then no.  Forty years ago, you could argue that program proof techniques could work with structured code, but could not with goto's.  Today, they work just fine with goto's - and especially with the very restricted kinds of goto's that are at issue here.

If you're talking about code reviewing and such ... it depends.

> 
> I'd just like some thoughts from people who worked with this sort of software. An answer to the question "Isn't there some big way to do things such that it will be easier to know if it's fully correct now". (this is not about functional vs imperative programming, just about validatable style)
People have been promising that their approach to programming will eliminate bugs and make verification easy for as long as there have been programming languages.  We've learned a few things *not* to do, and they help; but nothing we have so far makes an overwhelming difference.

It's possible to write bad, unvalidateable code in every language.  It's not even particularly challenging.  It's also possible to write good code in almost every language (well, perhaps not Intercal http://catb.org/esr/intercal/intercal.ps), if you're disciplined enough.  (It's widely believed today that it's impossible to write good, understandable, validateable in assembler.  Those who believe this have probably never seen a non-trivial program written in assembler by a good programmer.  There were conventions for writing in assembler that made it quite readable, understandable, and verifiable.  I certainly don't recommend going back to coding in assembler, but understanding *why* that would be a bad idea, rather than just taking it as received wisdom, is important.  Back when I taught programming languages, I made it a point to show students some of the *good* features of PL/I, not have them just repeat the old saw that "if you want PL/I, you know where to get it".  People who did well in my classes would likely choose C over PL/I for many problems - but they could give you good reasons for doing so.
                                                        -- Jerry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4813 bytes
Desc: not available
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20140305/5b683269/attachment.bin>