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: seimarao@gmail.com
Newsgroups: comp.compilers
Subject: Re: Self-modifying code, Function pointers & { Safety, Security}
Date: Thu, 20 Mar 2014 00:42:20 -0700 (PDT)
Organization: Compilers Central
Lines: 17
Sender: news@iecc.com
Approved: comp.compilers@iecc.com
Message-ID: <14-03-052@comp.compilers>
References: <14-03-015@comp.compilers>
NNTP-Posting-Host: news.iecc.com
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
X-Trace: miucha.iecc.com 1395325851 64411 2001:470:1f07:1126:0:676f:7373:6970 (20 Mar 2014 14:30:51 GMT)
X-Complaints-To: abuse@iecc.com
NNTP-Posting-Date: Thu, 20 Mar 2014 14:30:51 +0000 (UTC)
Injection-Date: Thu, 20 Mar 2014 07:42:21 +0000
Keywords: design, code
Posted-Date: 20 Mar 2014 10:30:51 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:1174

> [The major reasons for self-modifying code historically were for
> address modification for indexing and subroutine returns.  Index
> registers and indirect addressing provide instruction modification as
> the instruction is executed, making those modifications go away.  For
> runtime code generation, there have been a variety of approaches to
> controlled addition of code to running programs, which I could dig up
> if people care. -John]

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 will proceed on these two premises if only others advised.

Sincerely,
Seima Rao.