Most new popular languages don't have eval (Swift, Kotlin, Rust, Go) and even in those that do it's easy to avoid using it.
-
-
-
It's nearly impossible to make large C projects without memory corruption and other UB bugs slipping in. Banning eval is easy.
-
Banning large classes of memory corruption in C is also easy. People don't do it.
-
Banning eval in a program that handles _crash dumps_ should have been a no-brainer. Oops.
End of conversation
New conversation -
-
-
eval() tends to have pretty well defined behaviour
-
But it's a "feature" that exists purely for the sake of writing insecure code.
-
my REPLs are indeed meant to provide arbitrary code execution, but I'm quite okay with that
-
you have to *actually call eval* for it to run — not so much for UB/memory unsafety
-
Vast majority of UB/mem-unsafety in C is traceable back to doing idiotic things ppl should know not to do.
-
a lot of it is subtle enough that we have a hard time building static analysis tools for finding them
-
writing something that analyses a (dynlang!) program for whether it can get hold of eval is often significantly easier
End of conversation
New conversation -
-
-
does rust have an eval?!? how do they even do this, do they link a compiler?
-
Well not quite all. :-)
End of conversation
New conversation -
-
-
I think b/c UB in C and C++ can be very surprising to those w/o deep knowledge. Same reason why UB questions on SO do so well.
-
e.g. look at the top(voted) UB SO quest: http://stackoverflow.com/questions/tagged/undefined-behavior?sort=votes&pageSize=50 …
-
great, you reminded me that this exists, thanks a lot http://stackoverflow.com/questions/31739792/is-uninitialized-local-variable-the-fastest-random-number-generator …
-
it is a great question! A lot of misconceptions here probably due to openssl using this technique, more eyes better.
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.