DavidBruant · April 24, 2012 16:04
diff --git a/gistfile1.txt b/gistfile1.txt
 "An entire class of security vulnerabilities (buffer overruns, use-after-free, stack overflow) basically cease
 to exist for programs running in a garbage-collected environment (to be replaced by exciting new security
 vulnerabilities such as SQL injection, but that’s another story)."
 => SQL injections are unrelated to how memory is managed. SQL injections mostly come from denying the structure
 of an SQL query by representing it as a string.
 As a consequence, SQL injections could exist in C-memory-model languages. Think of a bash program that would accept
 constants and append it to a prepared string (in C). The program would be vulnerable to SQL injections as well.

 "The problem with garbage collection is that, now that memory management isn’t explicit (i.e. that when to recycle
 memory can’t be statically known by the compiler anymore), lifetimes have to be discovered at runtime"
 => It's certainly a hard problem, but in some cases, it certainly could still be done statically. In JavaScript,
 some memory is allocated (strings, objects, etc.) during a function call and if what is being allocated is not
 pushed outside of the function scope, then the memory could be free'd right away


 "Fortunately, the research landscape offers some promising potential solutions, which I’ll cover next time."
 => I'm looking forward to it :-)
	"An entire class of security vulnerabilities (buffer overruns, use-after-free, stack overflow) basically cease
	to exist for programs running in a garbage-collected environment (to be replaced by exciting new security
	vulnerabilities such as SQL injection, but that’s another story)."
	=> SQL injections are unrelated to how memory is managed. SQL injections mostly come from denying the structure
	of an SQL query by representing it as a string.
	As a consequence, SQL injections could exist in C-memory-model languages. Think of a bash program that would accept
	constants and append it to a prepared string (in C). The program would be vulnerable to SQL injections as well.

	"The problem with garbage collection is that, now that memory management isn’t explicit (i.e. that when to recycle
	memory can’t be statically known by the compiler anymore), lifetimes have to be discovered at runtime"
	=> It's certainly a hard problem, but in some cases, it certainly could still be done statically. In JavaScript,
	some memory is allocated (strings, objects, etc.) during a function call and if what is being allocated is not
	pushed outside of the function scope, then the memory could be free'd right away


	"Fortunately, the research landscape offers some promising potential solutions, which I’ll cover next time."
	=> I'm looking forward to it :-)