[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