Re: OpenSSL development (Heartbleed)

[Alan Browne <alan.browne@FreelunchVideotron.ca>]

On 2014.04.20, 04:17 , Georg Bauhaus wrote:
> On 19/04/14 22:53, Alan Browne wrote:
>> Now, do you really think the industry will change to something more
>> formalized and requirements driven?  Use Ada as a fundamental building
>> block of it?
>
> Where C (or no S/E) is being used, directly, or indirectly by using
> libraries written in C, the industry seems stuck in a loop of at least
>
> (1) self-referential confirmation,
> (2) insufficient irritation caused by C (or lack of S/E), and
> (3) sufficient competitive equality.
>
> One faint hope that I currently maintain is that some BigCo, not the
> industry, might produce a change to using C. The change might be like
> the ones just now performed in the case of hugely popular languages:
> PHP might become Hack everywhere because Facebook has produced Hack by
> "enhancing" PHP; Microsoft has already produced C#, VB#, etc., by
> "enhancing" each of the respective assimilated languages; Apple's
> "enhanced" C in Objective-C is already far above what the C standard
> requires of an implementation if seen through the lenses of their
> static analyzer. Google makes their talented staff spend some "free"
> time on "enhancing" the special qualities of JavaScript.
>
> And the results are all free, working, and ubiquitous.

Is it possible to identify a particular client side layer item (app, 
transport, internet or link) that is relatively small that could be 
designed and written in Ada and that could "drop in" as a replacement?

Obviously it would have to hook up and down in the system and 'look' for 
all intents and purposes like its C predecessor?

That would be a good proving ground for an Ada approach.  How to link 
them to the "C" code above and below ....
  __
> [*] One anecdote I heard was about two teams, one using C++, the
> other using SPARK, programming to the same specification for one
> year. Either team could use a simulator. The teams were tasked with
> producing programs for driving a test device. The C++ team
> debugged their software into existence, frequently testing in the
> simulator. The SPARK team first found a bug in the specification,
> then went on to prove software into existence, hardly if ever using
> the simulator. Finally, the C++ team had implemented 80% of the features.
> Some bugs were found in the final product. The SPARK team had
> implemented 100% of the features (close to closing time). No bugs
> were found in the final product.
>    Interpretation of the result: Use of the approach of C++ is
> preferable since project management then does not suffer a heart
> attack because they have no facts to report while the project
> is underway.

Amusing.  But there's nothing to prevent progress reporting on 
non-spiral development - the gates just have to be defined correctly.

Reminds me of a programmer assigned, alone, to write the software for an 
avionics system.  He chose assembler on a microprocessor for which he 
had no experience.  (We were not yet at the "ban assembler" point).

He designed (eg: wrote the documentation to full draft).  He followed 
the new programming style guidelines from our SQA.  He coded (hand 
written - believe it or not).  When his code was 100% written to spec, 
he and a word processing girl began entering the source code (she worked 
about 10x faster than him).

Then, with 100% of the code entered, he began assembling the files.

Then, through generated errors and in examining the machine code, he 
discovered that his understanding of the register set and memory model 
of the 8086 were completely wrong.

So.  He went back to his desk and began re-coding the entire thing in 
assembler again.  Hand written.  (But this time handed them off to the 
WP lady to enter the next day).  The re-coding didn't take very long 
since the overall design did not change at all.  (This is really the 
important part).

He assembled.  He corrected.  He loaded the code onto the engineering 
prototype h/w and found a few bugs.

 From the first loadable executable to an on-spec bug free system took 
less than a working week (he worked 10 to 6.  No more.  No less.  Ever). 
  He didn't use the nice ICE system we had.

And ahead of schedule.

This rare discipline in programming I've never seen since.

The funny thing was he was a mathematician and didn't like computers 
much - but had found a job as a programmer...

-- 
"Big data can reduce anything to a single number,
  but you shouldn’t be fooled by the appearance of exactitude."
      -Gary Marcus and Ernest Davis, NYT, 2014.04.07