The lite-C compiler is a pretty lightweight thingy for using the engine - it was never intended to replace 'real' c-compilers.
If you have 'a clue' about assembler then why would you take the limitations of lite-c instead of using f.i. c++?
Mostly because SED lacks basic features that are pretty much standard when developing larger programs

Yeah, SED is really far far behind a real IDE, but this is imo no reason to castrate the compiler...
And for the record: I use a C++ compiler for my library and this isn't a Lite-c only project, in fact its just a port and I don't want to maintain two versions of my library (Once the normal one and then the Lite-C one with dll and extra header).
Even a simple inline assembler would do the trick.

Edit: Und wenn ein inline assembler auf gar keinen Fall rein kommt, wie wäre es mit der Möglichkeit .s files direkt zu kompilieren? Das bisschen um eine Funktion herum is ja jetzt auch kein Hindernis.

this is a security risk and should definitely not work. that's exactly how hackers inject code and execute it. i thought this would be gone with the no execution bit on newer processors...

Thats not a security risk and not the same way hackers inject code into your application.

However, I agree that this isn't the nicest and cleanest solution and that there is a need for an official inline assembler function/macro/what ever.

It is. I'm not sure this works anyway (haven't tested it) since the function is not on the heap when you define it as static variable. I thought you'd have to allocate space on the heap, but I could be mistaken here. Anyway, I don't think the memory page you're writing your data into is marked PAGE_EXECUTE_READWRITE. I think you have to call VirtualProtect to change that.
Implementing this one could even write an own inline assembler.

No it isn't. The memory is accessible for your application and the kernel. There is no way to let user input new commands so every other access would result in an segfault.
What hackers uses are overflows to inject new code, thats why strcpy() is a bad function.

let's ask allmighty wikipedia:

That's why DATA memory should NOT be allowed to be executed. You say there is no way to let users input new commands? But in your next sentence you tell us how... well, the segmentation fault should occur if you try to execute data memory.

Interesting, you all mighty wiki says its in the last sentence:


The posted code is in no case a buffer overflow and also not a stack overflow.
I told you that you can inject new code when you let the user write into the memory by eg. don't check your strings but just use strcpy. That is _NOT_ the case in the sample code.

Segfaults should also not occur when you try to execute something from the heap but only when you try to access unmapped memory.

Of course your code is not a buffer overflow. That's not what I'm talking about. I meant executing data memory. You began talking about how that can be done - via a buffer overflow or whatever. And that's why you shouldn't be able to do it. Simples.

No, you have mistaken me. Your point was that the code is evil because hackers use this to inject new code. I wanted to show you that you are wrong because the code isn't evil, I never wanted to argue about the NX-Bit or the evil heap. (Did you know that you can also have code on the stack and execute it? What about an NX-Bit for the stack?)

And by the way, instead of writing save code without using functions that are clearly marked as evil (like strcpy), you want to prevent anyone from executing something from the heap? Thats like saying "Ouh, my teeth hurts like hell. Lets cut of my head so I don't feel 'em anymore"
Just my 2 cents about the NX-Bit