Hacker News Reader

Comment by stcredzero | Hacker News Reader

If a given piece of software has been largely written using certain patterns or conventions, then it is often possible for a syntactic rewrite engine to be able to match those patterns, then output idiomatic code patterns in the target language.

This may well be applicable to kernels and other constituents of an OS.

View on HN

Have you even looked at the source code to glibc? It's stuffed full of macros and #ifdef hell. Not to mention symbol versioning, the use of gcc-specific compiler extensions, and ancient-UNIX-beard performance hacks. You'd have more success teaching a chimpanzee to play the violin, than automatically translating glibc into anything.

I've seen a lot of weird preprocessor (ab)use in GNU code. The coreutils true/false (of all programs to invoke clever preprocessor tricks...) has this gem:

in true.c (all told, an 80-line file):

  /* Act like "true" by default; false.c overrides this.  */
  #ifndef EXIT_STATUS
  # define EXIT_STATUS EXIT_SUCCESS
  #endif

false.c, of course, contains only:

  #define EXIT_STATUS EXIT_FAILURE
  #include "true.c"

On my current system, each of these represents a stately 27KB dynamically linked executable.

By way of comparison, the OpenBSD version of true comprises nine lines with zero preprocessor directives:

  /*	$OpenBSD: true.c,v 1.1 2015/11/11 19:05:28 deraadt Exp $	*/

  /* Public domain - Theo de Raadt */

  int
  main(int argc, char *argv[])
  {
  	return (0);
  }

If I write something and make it simple, how will people know what a jenius I am?

But BSD true doesn't support --version, how are you going to check your version of true without a locale-aware version string (and yes, gnu true is locale-aware, and contains 2k of strings including 48 encoding names and 36 format strings — 10 of which are duplicates, and for some reason refers to the SHA2 utilities)

(I dimly remember an essay about similar issue in a similar mainframe command (maybe in JCL?) taking a bunch of revisions to actually get right?)

Then what chance do we have of cleaning it up?

It does seem to me though that if you pre-processed it for a common case and translated it to rust with anything going into unsafe if it has to and started from that you would be off to some sort of start.

The whole thing seems moot though because there are already alternate libc implementations like musl as well as alternate malloc implementations like jemalloc.

I actually still don't understand why libc is the undertaking it is made out to be, especially if you can plug in jemalloc which I would think would take care of the most difficult part.

So I guess we need more than just a "transliteration" to a safer language. We really need to shed that cruft and write something clear and understandable.

Could we also drop a lot of requirements that applied to older, more limited hardware? (Or, do certain constrained hardware situations still require most of those requirements to stick around?)

Isn't that just what a compiler is, where the target language is machine code?

A compiler has more than syntax though, since it understands semantics and does a lot of checks. I think the parent comment refers to something a little more rudimentary, like a macro-based system to do a rough translation of code.

yeah this is like a recipe for turning an N-pass compiler into an N+1 pass compiler

I realize something like glibc would be the LAST set of source code to run through a transpiler, but how hard do folks think it would be to make a C -> Rust transpiler? I'd think you'd go about it by making Rust a target backend for LLVM. This way you let LLVM deal with the all C stuff (macros, etc), and just focus on the internal representation to Rust conversion. In theory, you'd get C++ to Rust as well.

Chances is successfully going from some not-so-obfuscated C code to equally not-so-obfuscated Rust code?

> how hard do folks think it would be to make a C -> Rust transpiler?

Why do you want to do that? The only way to make it work short of doing years and years of static analysis research to automatically translate ad-hoc memory management disciplines into those of Rust (that I think will not succeed anyway) would be to compile to unsafe code. And if you compiled to unsafe Rust code, there would be no gain.

I'm not sure it would take "years and years" of static analysis research. You could use the data-flow analysis that is built into LLVM, then punt on the rest. It doesn't HAVE to produce Rust code that compiles 100% of the time. The goal would be to run it through the transpiler so you have a starting place to produce Rust code that compiles and works the same as the original C code.

Again, this might be a terrible idea, but I'd be curious to hear from anyone that has experience with this sort of porting...

Data flow has nothing to do with the hard problems you'd have to solve.

Generally the opinion is "it might work but it would be terrible Rust," and given that FFI into C has no overhead, replacing things a symbol at a time might be a better approach to this kind of problem.

> hard do folks think it would be to make a C -> Rust transpiler

Easy. But it won't be too useful.

Rust isn't a compiler that magically finds memory errors. Transpiling C code to Rust will not find those memory errors unless you have a really good transpiler that can detect the overall structure and design of the C code. It will just give you a ton of Rust error messages; probably none of which relate to an actual memory error. (Or you transpile to `unsafe` rust, in which case, what was the point?).

Rust works with a set of rules, and these rules enforce some things in your programming/software design style. This enforced style (i.e. the discipline around memory usage) is what gets us memory safety. This style is not the same as the style used in programming C/C++; so a dumb transpilation won't work. You need to write a transpiler that can figure out what logic the code (and not just for a function, for a larger unit) was trying to encode, and write that in Rust. That's ... a nontrivial problem to solve with a transpiler, probably requiring AI skills. It's a mostly trivial thing to do as a human, since mostly such "transpilation" involves noticing a few key issues (related to highly-shared structs and whatnot) and fixing them (leaving most of the code the same).

Reply on news.ycombinator.com