Isn’t an easier and better source of resource utilization just to farm out each program under consideration to “the crowd” and say, rewrite dnsd in Go.
For security verification purposes, you’d be going through each line of the converted program anyway. I still think it would be a nearly impossible task given the C code in the wild - outside of threading, the common usage of ‘unions’ - there is no way I know of to map these to a simple Go struct, or even several - you need something like protobufs. So even if you could convert, you’d end up with code that is probably harder to maintain/verify than the original C code. If it is just memory safety you require, you can already do this with C in many ways - https://www.doc.ic.ac.uk/~phjk/BoundsChecking.html > On Jan 4, 2019, at 1:05 PM, Eric S. Raymond <e...@thyrsus.com> wrote: > > jake6...@gmail.com <jake6...@gmail.com>: >> On Thursday, January 3, 2019 at 5:46:39 PM UTC-5, Eric Raymond wrote: >>> >>> On Thursday, January 3, 2019 at 12:11:06 PM UTC-5, Jake Montgomery wrote: >>>> >>>> I would note that any tool that ports from C++, or even C, to Go is going >>>> to produce ugly, unmaintainable, and non-idiomatic code, at best. >>>> >>> >>> These are two different cases. I agree that graceful C++ to Go >>> transpilation is effectively impossible. >>> >>> On the other hand, I believe graceful, comment-preserving C to >>> idiomatic-Go transpilation is almost possible. >>> >> >> I might believe that it could be comment-preserving and possible graceful, >> and pretty much human readable. But I seriously doubt that it could ever >> produce anything I would call idiomatic-Go. Perhaps we have different >> definitions of that term. > > Yes, we do. > >> Aside from the line by line form, I also mean >> "something that an experienced go programmer might write." Idomatic-Go by >> my definition, would include the use of things like interfaces and methods. >> It uses goroutines and channels where appropriate. That is what you want if >> you want "real" go code that is usable and maintainable. > > Mine is less ambitious than yours. I was implying something more like > "What a Go programmer would write if he were confined to the subset of Go > features rougly equivalent to C, plus real strings and garbage correction." > And replacing pointer walks with iteration - all that sort of thing. > > Possibly a better description that "idiomatic" would be "line-by-line > translation that a Go programmer could read without wanting to barf." > And perhaps I should have said "maintainable" code rather than "idiomatic", > because my real intent was to contrast against the kind of horrifying > pseudo-assembler-like splooge that leaven and c2go generate. But I did mean > idiomatic, if in a relatively weak sense. > > If this seems too weak to be interesting, remember my strategic objective. > I want to get critical infrastructure out of a memory- and type-unsafe > language that is difficult to verify in into a (more) memory- and > type-safe one in order to armor it against CVEs, basically. NTP would > be my first target but by no means my last. > > Go is not perfectly memory-safe, alas, but is the first plausible > target for such a mechanized jump out of C-land that I've seen. > > Perfectly idiomatic Go isn't required for this objective, just > maintainable Go that would tend to evolve into more strongly idiomatic Go as > more human hands touch it after translation. > > So you understand my thinking better, here's a design sketch: > > Perry Metzger, one of a relatively small number of people I consider > better qualified than me to do the job, is working on a comment and > whitespace-preserving C source-code walker that will emit > S-expressions describing an AST with some semantic annotation (types, > variable scopes, that sort of thing). > > My plan is to bolt this to a rewrite engine, probably written in Lisp, > and a growing database of rewrite rules that transform the AST from > C-like to Go-like. It looks like the core language mapping won't > actually be very difficult; I expect most of the production rules will > actually be about mapping C library calls to Go library calls. Doing > a reasonably complete job of *that* is going to be a hairball, it's most > of why I'm estimating two years. > > Third stage: AST goes to prettyprinter and you get Go...almost. > > A crucial part of the design is that the rewrite engine will pass > through, marked "this is still C", AST spans that it can't map. > I don't expect the percentage of such spans to go entirely to zero; > the goal is, rather, to get those residuals small enough that even on > large codebases one human developer can finish off the grotty spots. > > Another crucial part is that rewrite-rule development cam be > crowdsourced, and people can build their own rulebases for their > own C APIs. > > I'll declare victory when I can lift the NTPsec codebase out of C with > this thing. > > But this is just a plan in my head right now. I won't have time to do it > until I can leave NTPsec in a stable, reasonably finished state. And then > I'lll have to scare up funding. > -- > <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a> > > My work is funded by the Internet Civil Engineering Institute: > https://icei.org > Please visit their site and donate: the civilization you save might be your > own. > > > -- > 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. -- 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.
