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

federation2005@netzero.com
Sun, 13 Apr 2014 12:41:24 -0700 (PDT)

          From comp.compilers

Related articles
Self-modifying code, Function pointers & { Safety, Security} seimarao@gmail.com (Seima Rao) (2014-03-07)
Re: Self-modifying code, Function pointers & { Safety, Security} kaz@kylheku.com (Kaz Kylheku) (2014-03-09)
Re: Self-modifying code, Function pointers & { Safety, Security} martin@gkc.org.uk (Martin Ward) (2014-03-14)
Re: Self-modifying code, Function pointers & { Safety, Security} tenger@iseries-guru.com (Terrence Enger) (2014-03-15)
Re: Self-modifying code, Function pointers & { Safety, Security} seimarao@gmail.com (2014-03-20)
Re: Self-modifying code, Function pointers & { Safety, Security} federation2005@netzero.com (2014-04-13)
Re: Self-modifying code, Function pointers & { Safety, Security} monnier@iro.umontreal.ca (Stefan Monnier) (2014-04-16)
| List of all articles for this month |

From: federation2005@netzero.com
Newsgroups: comp.compilers
Date: Sun, 13 Apr 2014 12:41:24 -0700 (PDT)
Organization: Compilers Central
References: 14-03-015 14-03-052
Injection-Date: Sun, 13 Apr 2014 19:41:24 +0000
Keywords: theory, code
Posted-Date: 14 Apr 2014 00:27:36 EDT

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.


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.