Re: Self-modifying code, Function pointers & { Safety, Security}

Path	csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!news.misty.com!news.iecc.com!.POSTED!nerds-end
From	federation2005@netzero.com
Newsgroups	comp.compilers
Subject	Re: Self-modifying code, Function pointers & { Safety, Security}
Date	Sun, 13 Apr 2014 12:41:24 -0700 (PDT)
Organization	Compilers Central
Lines	25
Sender	news@iecc.com
Approved	comp.compilers@iecc.com
Message-ID	<14-04-012@comp.compilers> (permalink)
References	<14-03-015@comp.compilers> <14-03-052@comp.compilers>
NNTP-Posting-Host	news.iecc.com
Mime-Version	1.0
Content-Type	text/plain; charset=ISO-8859-1
Content-Transfer-Encoding	7bit
X-Trace	miucha.iecc.com 1397449656 79622 2001:470:1f07:1126:0:676f:7373:6970 (14 Apr 2014 04:27:36 GMT)
X-Complaints-To	abuse@iecc.com
NNTP-Posting-Date	Mon, 14 Apr 2014 04:27:36 +0000 (UTC)
Injection-Date	Sun, 13 Apr 2014 19:41:24 +0000
Keywords	theory, code
Posted-Date	14 Apr 2014 00:27:36 EDT
X-submission-address	compilers@iecc.com
X-moderator-address	compilers-request@iecc.com
X-FAQ-and-archives	http://compilers.iecc.com
Xref	csiph.com comp.compilers:1219

Show key headers only | View raw

On Thursday, March 20, 2014 2:42:20 AM UTC-5, seim...@gmail.com wrote:
> I was planning to discontinue self-modifying code entirely.
> For runtime code generation, I was planning to bank entirely
> upon runtime hooks(mapping instructions of an interpreter to
> API hooks).

I think the brunt of the Halting Problem comes down to this very matter and
can probably be summed up in a simple way that there are no finite number of
fixes that completely account for all the things you may want or *need* to do
with self-modifying code. Instead, you have a set of standard "fixes" that
appear to meet most needs (e.g. the "loader" for run-time loading a program,
the "branch prediction" of some CPU's for handling the "nop" to jump
conversion at run-time, the "relocator" for handling "nop" to op at load time,
etc.). But no finite set of "standard fixes" or "utilities" for the various
special cases (nor even an *infinite* set of such fixes, if they are
recursively enumerable) will exhaust all the things you may want or need to
do.

What I'm not sure of is this question: is there way of actually defining
"no-modifying" algorithms that leads to a *positive* resolution for the
halting problem? I suspect there is and that it may be directly tied to the
formalism for linearly bounded automata (the automata for context-sensitive
languages).

Tha halting problem is solvable for linearly bounded automata.

Thread

Self-modifying code, Function pointers & { Safety, Security} Seima Rao <seimarao@gmail.com> - 2014-03-07 21:34 +0530
  Re: Self-modifying code, Function pointers & { Safety, Security} Kaz Kylheku <kaz@kylheku.com> - 2014-03-09 20:36 +0000
    Re: Self-modifying code, Function pointers & { Safety, Security} Terrence Enger <tenger@iseries-guru.com> - 2014-03-15 09:29 -0400
  Re: Self-modifying code, Function pointers & { Safety, Security} Martin Ward <martin@gkc.org.uk> - 2014-03-14 14:15 +0000
  Re: Self-modifying code, Function pointers & { Safety, Security} seimarao@gmail.com - 2014-03-20 00:42 -0700
    Re: Self-modifying code, Function pointers & { Safety, Security} federation2005@netzero.com - 2014-04-13 12:41 -0700
      Re: Self-modifying code, Function pointers & { Safety, Security} Stefan Monnier <monnier@iro.umontreal.ca> - 2014-04-16 09:18 -0400

csiph-web