4 ms·
I think it's a bit disingenuous to say that such dislike is nailed to Lisp. Mixing data and code in the memory of a running program is what has lead us to every
by wendroid 16y ago
I think it's a bit disingenuous to say that such dislike is nailed to Lisp. Mixing data and code in the memory of a running program is what has lead us to every exploit involving a buffer overflow or a stack smash.
I expoect a different class of problems in their place but self modifying code is rightfully highlighted as unprovably correct.
Lisp is not the only language that can build a string and throw it at an eval function.
- jpr 16y ago> Mixing data and code in the memory of a running program is what has lead us to every exploit involving a buffer overflow or a stack smash. Not exactly. The totally unsafe programming model of C is what has caused this. Once you have untyped pointers that need not point to objects owned by your program, it is very easy to fuck something up. > Lisp is not the only language that can build a string and throw it at an eval function. Well, evaluating a string in (Common) Lisp just returns the string. Evaluating a symbol or list will actually do something interesting.
- wendroid 16y agoWell, you know what I mean re: the last bit, it's not just Lisp that can modify code at runtime. As for C, it's not just the fault of pointers. You just can't shellcode something that doesn't execute data. Like I say, we'd just have a different class of problems, so it's not a panacea.
- wendroid 16y agoI should also say that I have experience working with Manchester cpus (AVR microcontrollers) where the code is fixed when you flash it and you cannot jmp into RAM. Of course one then writes an interpreter instead :)