InsideQC Forums

Is it possible to allocate a small function at run-time?

I don't have much of a reason to want to do this that couldn't be done by a macro, but I was thinking of this:

entity->Think();

Where the allocated function goes like this:
I could just as easily write a macro:
#define THINK_ENT(_ent) _Think(_ent) // Yes this is a stupid macro, but I'm thinking of more complex applications of this ultimately with more arguments...

Or call the function directly. I just enjoy exploiting C capabilities to the max. Sadly, during the course of writing this, I've already thought of a way to maybe explore this that goes like this ....
Then I get the memory address of Think1 and Think2 and Think3 and copy the piece of memory that Think1 uses (&Think1 to &Think2) using memcpy to locate the pointer address that needs changed (and it seems to me that would be platform independent).

Thoughts? Would I accidentally piss off anti-virus or something by doing this or make an operating system security model mad at me that maybe uses certain addresses for execution and certain addresses for storage?

I really don't get what you're asking.

If you're talking about function pointers, void (*foo)(void); foo = realfunction; foo();
If you're not then you can't just copy blocks of instructions around. For one thing you've no idea where the function ends. Most instructions have hard-coded addresses in them, any given function will have both relative and absolute addresses. Even in PIC code, the data address is typically calculated relative to the instruction pointer. Change the instruction pointer and you change the data address too, and that's not something you want.

If you want to generate native instructions yourself then by all means do so, but this of course requires that you know how to write out the correct addresses in each instruction that you use. Either way, you need full control over the instructions and the addressing used. A C compiler doesn't give you that sort of control, you'll only get that from writing the instructions yourself (either via asm, or via C code).

Also program code is stored in write-protected memory areas on modern OSes -- trying to memcpy Think2 over Think1 is going to cause a general protection fault or segmentation violation.

Unless you absolutely need to create executable code yourself -- don't do it. You will need OS-specific code to allocate or mark the memory area as executable, and the instructions will only work on a single architecture of CPU.

Some existing code to look at: Quake3 source, code/vm_x86.c

^^^ what Spike and andrewj said. You cannot directly manipulate executable code in any modern OS like you do with data; it lives in protected, usually read-only (at least at OS user level) memory segments. In a OS with a really good security model, you can't even figure out *where* in the memory the code is allocated, let alone change something on it.

What exactly are the uses you have in mind for this ?

frag.machine wrote:What exactly are the uses you have in mind for this ?

I can't think of any real reason I would need to do it.
I dynamically allocate about everything now and create multiple instances of about everything, freeing an allocated function would be no more overheard than freeing a string.

But appears this is "bad idea". I probably could have used it hardcode some fixed parameters into another otherwise void function. But was clearly not necessary as an only way to do anything that I can think of.