[Cryptography] "NSA-linked Cisco exploit poses bigger threat than previously thought"

Dan McDonald danmcd at kebe.com
Fri Aug 26 22:07:56 EDT 2016


On Fri, Aug 26, 2016 at 12:42:23AM -0700, Ron Garret wrote:

<SNIP!>

> C has (at least) one serious flaw even when judged as an assembly language:
> the only way to do a transfer of control outside of the current function is
> to either call another function or return to the callee.  You can’t GOTO a
> label outside of the current function.  That makes it impossible to
> implement tail recursion in pure C unless you compile your entire program
> into a single C function.

An academic language for concurrency I learned in grad school -- SR -- had a
concept that, while used as one point on one axis, could be used for a
goto-like construct you suggest.

SR had a 2-by-2 abstraction matrix: call & send were one syntactically
identical axis, and proc & in were the other.  The combinatorics are:

send --> proc  ====> Thread creation (or remote program creation... SR's
runtime did remote too)

send --> in    ====> Message passing.

call --> proc  ====> Procedure call (remote or local)

call --> in    ====> Thread rendezvous ( in() is a blocking operation).


Could one do a variant on call --> in to have multiple entries into a
function at various points within it?  I see assembly routines with such
properties a lot.


Not my biggest beef with languages today (that'd be the absurdity that
there's no byte-order-specific data typing, see
http://kebesays.blogspot.com/2009/06/endian-independence-not-just-for-kernel.html
for my full rant), but SR's call/send ==> proc/in could be used for things
like Ron describes.


Dan


More information about the cryptography mailing list