It was actually a different but related thread about converting C to Go…. the link I sent was https://www.doc.ic.ac.uk/~phjk/BoundsChecking.html <https://www.doc.ic.ac.uk/~phjk/BoundsChecking.html>
> On Jan 10, 2019, at 12:20 PM, Jesper Louis Andersen > <jesper.louis.ander...@gmail.com> wrote: > > This must have been before I started reading this thread, but I know of the > CCured project by George Necula et.al <http://et.al/>, which is a C-to-C > translator: > > https://web.eecs.umich.edu/~weimerw/p/p477-necula.pdf > <https://web.eecs.umich.edu/~weimerw/p/p477-necula.pdf> > > On Thu, Jan 10, 2019 at 6:22 PM robert engels <reng...@ix.netcom.com > <mailto:reng...@ix.netcom.com>> wrote: > Again, what is wrong with the bounds checking/memory protection > library/technique for C I referred you to? Even a decrease in performance > will probably still be on par or better than the equivalent Go program. > > Much simpler and efficient. > >> On Jan 10, 2019, at 10:49 AM, Jesper Louis Andersen >> <jesper.louis.ander...@gmail.com <mailto:jesper.louis.ander...@gmail.com>> >> wrote: >> >> On Wed, Jan 9, 2019 at 7:55 PM 'Thomas Bushnell, BSG' via golang-nuts >> <golang-nuts@googlegroups.com <mailto:golang-nuts@googlegroups.com>> wrote: >> >> I'm curious about why transpilation would have significantly mitigated the >> Heartbleed bug. >> >> >> Heartbleed is a bug which relies on two things: >> >> - Failure to do proper bounds checking >> - Allocation of a buffer which is not initialized to some zero-value, and >> which straddles memory it shouldn't. >> >> Many programming languages are constructed such that they address both of >> the above problems at the semantics level, and thus they avoid the really >> dangerous part of the bug, which is the leak of information, downgrading the >> bug to a denial of service attack, or even also mitigating that part of the >> bug. Array access is checked against the arrays bounds, and buffer allocated >> memory is properly 0-initialized before use. >> >> Compilation from one language to another might have the side-effect of >> changing the semantics of the program because of the above observations. >> Thus making a previously unsafe program safe. In principle we want to be >> clever: augment the program with new safety semantics, but without changing >> the meaning of the rest of the program in any way. >> >> Given there is a very large body of C code out there, live, we want to take >> an approach like the above: >> >> - A rewrite, into say Rust because it is currently popular, runs the risk of >> re-introducing faults in the programs which were removed through corrections >> over the years. >> - We rewrite too much, where we should reuse. >> - C is a remarkably stable programming language in that most older C code >> still runs in this day and age. More or less, there are some caveats, which >> the compilation idea ought to address. Many modern languages have a >> tremendous amount of bit-rot in the sense even 2-3 year old programs now >> utter fail to run. >> >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts+unsubscr...@googlegroups.com >> <mailto:golang-nuts+unsubscr...@googlegroups.com>. >> For more options, visit https://groups.google.com/d/optout >> <https://groups.google.com/d/optout>. > > > > -- > J. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
