4 ms·
Better do not use Lisp, since the interpreters have at least around 10% C.
by namKS 6y ago
Better do not use Lisp, since the interpreters have at least around 10% C.
- phoe-krk 6y agoThey're compilers, not interpreters - or at least SBCL, CCL, ABCL, ECL, Clasp, CLISP, ABCL, and LispWorks are. I'm not aware of any other alive contemporary Common Lisp implementations. Lisp is a memory-safe language with automatic memory management, which removes all of the aforementioned classes of attacks that are available in C. In addition, the Lisp compilers are written in Lisp itself, not in C, which further decreases the attack vector. Also, the currently-in-progress SICL project intends to do away with C completely, even for its garbage collection and OS-interfacing parts.
- hmartins 6y agoCCL: Totals grouped by language (dominant language first): lisp: 336793 (84.60%) asm: 30410 (7.64%) ansic: 29862 (7.50%) sh: 718 (0.18%) objc: 299 (0.08%) java: 7 (0.00%) > Lisp is a memory-safe language with automatic memory management, which removes all of the aforementioned classes of attacks that are available in C. Yeah, right.
- phoe-krk 6y ago> Yeah, right. In Lisp, the programmer never frees memory themselves, so use-after-free and double-free are not triggerable by the user. Bound checks for all array types are in effect, so overflows are impossible. Strong typing and a lack of casting prevent type confusion. Do you have any arguments other than the unsubstantial "yeah, right"?
- deleted 6y ago[deleted]
- kazinator 6y agoLisp implementations using C means that the implementations may have C-related vulnerabilities, not Lisp programs themselves. You're not facing the risk of creating new C-related vulnerabilities by writing new application code in Lisp, even if the Lisp you're using has substantial amounts of the run-time written in C.