[HN Gopher] Eurydice: a Rust to C compiler
___________________________________________________________________
Eurydice: a Rust to C compiler
Author : todsacerdoti
Score : 172 points
Date : 2025-12-07 01:41 UTC (21 hours ago)
(HTM) web link (jonathan.protzenko.fr)
(TXT) w3m dump (jonathan.protzenko.fr)
| mustache_kimono wrote:
| Cool. One should perhaps mention some prior art:
| rustc_codegen_clr is an experimental Rust compiler
| backend(plugin), which allows you to transpile Rust into .NET
| assemblies, or C source files.[0]
|
| [0]: https://github.com/FractalFir/rustc_codegen_clr
| oconnor663 wrote:
| > We recommend using Nix to easily ensure you are running the
| right versions of the tools and libraries.
|
| Ooof I remember when everything used to be like this. Cargo has
| really spoiled me.
| ValtteriL wrote:
| Can Cargo install deployment tools like Ansible? I find myself
| using nix for those kind of tools despite how good $lang
| package manager is.
| ris wrote:
| Using nix to install Ansible, oof you're hurting me..
| antonvs wrote:
| Cargo isn't intended for that. If there was something like
| Ansible implemented in Rust, then you could use Cargo to
| install it.
| kamov wrote:
| You can use both Nix and Cargo at the same time, and they
| accomplish different things. Nix's purpose is more like rustup,
| except it works for each program on your computer
| skavi wrote:
| Cargo does not attempt to solve the same problems as Nix (if
| you depend on any software not written in Rust). A checked in
| Nix shell is genuinely great documentation on the expected
| system environment.
| apitman wrote:
| I use Rust and C at work. I quite enjoy Rust, but I currently
| have no reason to believe C won't outlive it, by a lot.
| po1nt wrote:
| Well, Fortran is still used somewhere too
| rahen wrote:
| You mean everywhere. It's just hidden behind abstraction
| layers or Fortran libraries like BLAS/LAPACK, which are used
| by NumPy, R, Julia, MATLAB, Excel, TensorFlow, PyTorch (for
| some backends), and basically anything that involves linear
| algebra.
| hu3 wrote:
| And I think Zig will gradually eat a large piece of the C pie
| that would otherwise be eaten by Rust.
| pjmlp wrote:
| I doubt it, unless it sorts out its use after free issues,
| embraces binary distribution used in commercial world, and
| gets adoption by an OS vendor.
| Zambyte wrote:
| You can create and link to shared objects and create
| statically or dynamically linked executables. What more
| could you want on "embracing binary distribution"?
| opem wrote:
| Jai is also on the que
| Y_Y wrote:
| ?Que jai?
| forgotpwd16 wrote:
| Nowadays, a language without public
| implementation/documentation isn't going to get any actual
| adoption.
| apitman wrote:
| Currently Zig has the same issues as Rust in this context,
| primarily depending on a compiler that's too complex for a
| single person to maintain if necessary.
|
| But in Zig's case it seems there's a pretty good chance that
| will change if they're able to drop LLVM in the future.
| pjmlp wrote:
| Until specific industry standards like POSIX, all Khronos APIs,
| UNIX like systems get rewriten into something else, it is going
| to stay around.
|
| Hence why it should be a priority for WG14 to actually improve
| C's safety as well, unfortunately most members don't care,
| otherwise we would at least already have either fat pointers,
| or libraries like SDS on the standard by now.
| thristian wrote:
| In 1983, AT&T released the fifth version of Unix, called
| "System V". Part of the release was an ABI specification for
| how the different parts of the system would talk to one
| another. Notably, the main portion of the spec described
| portable things like the file-format of executables, and the
| details for each supported platform were described in
| appendixes.
|
| The SysV ABI is still used to this day, although the
| specification itself has withered until only two chapters
| remain[1], and CPU vendors still publish "System V ABI
| appendix" documents for platforms that System V's authors
| could not have dreamed of[2].
|
| C as an interface is going to be around for a very long time,
| like POSIX and OpenGL and the SysV ABI standard. C as an
| actual _language_ might not - it might wind up as a set of
| variable types that other languages can map into and out of,
| like what happened to the rest of the SysV ABI specification.
|
| [1]: https://www.sco.com/developers/gabi/latest/contents.html
|
| [2]: https://wiki.osdev.org/System_V_ABI#Documents
| IshKebab wrote:
| The C ABI will definitely stick around. That doesn't
| necessarily mean C will. (Though it probably will have a very
| drawn-out death.)
| apitman wrote:
| > Hence why it should be a priority for WG14 to actually
| improve C's safety as well
|
| Sorry should have been more clear. I'm talking specifically
| about C89, or maybe C99.
| pjmlp wrote:
| It hardly makes a difference, regarding C's safety.
| mustache_kimono wrote:
| > I currently have no reason to believe C won't outlive it, by
| a lot.
|
| My reaction is kind of: "So what?" I really don't care about
| the relative lives of languages and don't really understand why
| anyone would. Unless I am wrong, there is still lots of COBOL
| we wish wasn't COBOL? And that reality doesn't sound like a
| celebration of COBOL?
|
| IMHO it would be completely amazing if magically something 10x
| better than Rust came along tomorrow, and I'd bet most Rust
| people would agree. Death should be welcomed after a well lived
| life.
|
| To me, the more interesting question is -- what if efforts like
| c2rust, Eurydice, TRACTOR and/or LLMs make translations more
| automatic and idiomatic? Maybe C will exist, but no one will be
| "writing" C in 20 years? Perhaps C persists like the COBOL
| zombie? Perhaps this zombification is a fate worse than death?
| Perhaps C becomes like Latin. Something students loath and are
| completely bored with, but are forced to learn simply as the
| ancient interface language for the next millennia.
|
| Is that winning? I'd much rather people were excited about
| tech/a language/a business/vibrant community, than, whatever it
| is, simply persisted, and sometimes I wish certain C people
| could see that.
| tormeh wrote:
| Honestly I'd be a bit disappointed if something better came
| along tomorrow. Just as we as an industry spent all this
| effort moving to Rust something better comes along? Lame.
| Obviously I want better languages to come out, but I'd either
| want a bit of warning or a slower pace so we as an industry
| don't totally "waste" tons of time on transitioning between
| short-lived languages. Thankfully languages need about 10
| years to mature from 0.1 to production readiness, and
| industry happily ignores marginally (and moderately) better
| languages than what they're using, so this is not a realistic
| issue.
| mustache_kimono wrote:
| > Honestly I'd be a bit disappointed if something better
| came along tomorrow.
|
| You'd be disappointed if something 10x better came along
| tomorrow? I suppose you would you also be disappointed if
| magically we had economical fusion power, because you own
| utility stocks? Or we invented 10x better new car, because
| you already own an old car?
|
| Of course the world wouldn't immediately move to one thing
| or the other, etc., and we'd still have a 10x better thing?
|
| > Obviously I want better languages to come out, but I'd
| either want a bit of warning or a slower pace
|
| The purpose of this thought experiment is to say -- it's
| perfectly fine for things to live and die, if they must.
| We've had a second Cambrian period for PLs. It's perfectly
| alright if some don't live forever, including Rust, which I
| really like.
|
| In my thought experiment, Rust and C could also accept this
| new paradigm, and _adapt_ , and perhaps become 10x better
| themselves. Though this is something heretofore C/C++
| haven't done very well. IMHO new things don't preclude old
| things, and there mustn't be only one winner.
|
| > Thankfully languages need about 10 years to mature from
| 0.1 to production readiness, and industry happily ignores
| marginally (and moderately) better languages
|
| Which my thought experiment did as well? Read: This is a
| 10x improvement!
| tormeh wrote:
| Oops, skipped the 10x part. If it's really 10x better
| that would indeed be amazing. That's basically the leap
| from C to Rust in domains that C is not good at.
| estebank wrote:
| If all Rust accomplishes is ushering some other better
| project, it would have been worth it.
|
| I think it would take a while for that to happen, purely
| due to momentum' the same thing that makes some people
| think that Rust isn't being used will affect any younger
| language just as much, if not more.
|
| I think that there's an easier language than Rust
| struggling to come out of it, but if Rust had been that
| easier language with different compromises, I doubt it
| would have gained critical mass that allowed it to get
| where it is today. Being fast and safe meant it carved a
| niche in a "free square" that drove it to have a clear
| differentiator that allowed it to gain an initial audience.
| I also suspect that it is easier toale a language fast and
| then evolve it to make it easier to use, than it is to make
| it easy to use first and then make it fast.
| pjmlp wrote:
| COBOL has enough business money around to get new tools and
| ISO standards[0], so it is unlikley to think otherwise
| regarding C.
|
| https://www.rocketsoftware.com/en-
| us/products/cobol/visual-c...
|
| [0] ISO COBOL 2023 - https://www.iso.org/standard/74527.html
| mustache_kimono wrote:
| > COBOL has enough business money around to get new tools
| and ISO standards[0], so it is unlikley to think otherwise
| regarding C.
|
| I don't think you understand my point. I am explicitly
| saying "C will definitely survive (like COBOL)". I am
| asking is that the kind of life people want for C?
| pjmlp wrote:
| Ideally we would have moved on into some Assembly glue +
| compiled managed high level languages by now, like Xerox
| PARC when then moved away from BCPL into Smalltalk,
| Interlisp-D, Mesa and Mesa/Cedar, but some folks and
| industry standards cannot let go of C, and those have to
| contend with that kind of life for C, exactly.
| uecker wrote:
| I plan to be writing C for the next decades even for new
| projects, because I think it is a great language, and I
| appreciate its simplicity, fast compilation times, stability,
| and portability.
|
| I am happy if people are excited about Rust, but I do not
| like it too much myself. Although I acknowledge that it
| contains good ideas, it also has many aspects I find
| problematic and which why I do not think we should all switch
| to it as a replacement for C.
| kace91 wrote:
| >it also has many aspects I find problematic
|
| Could you share those?
|
| Not trying to argue, just curious on the perspective of a C
| veteran, as someone who's just starting with lower level
| languages.
| uecker wrote:
| Mostly the advantages a listed for C: stability,
| portability, simplicity, fast compilation times could all
| in reverse also be considered disadvantages of Rust. I am
| also not a fan of monomorphization, not of static
| linking, and not of having many dependencies out of a
| large uncurated pile of many projects. I also think Rust
| is not pragmatic enough. Overall though, my main issue is
| complexity of the language which I think goes in the
| wrong direction - this may be ok if the alternative is
| C++, but if you prefer C to C++ then Rust is equally
| unappealing. At the same time I think the advantages of
| Rust are exaggerated. I still agree memory safety is
| important, I just think Rust is not an ideal approach.
| ahartmetz wrote:
| C strings (it's almost an exaggeration to say that C has
| strings) and "just never make any mistakes bro" based
| memory management come to mind.
| uecker wrote:
| We were talking about Rust issues. But yes, C should have
| a proper string type. But as long as it does not have a
| better standardized string type, it is possible to define
| your own (or use a library).
| ahartmetz wrote:
| Absolutely. Even when I preferred C over C++ (a long time
| ago), it was "but with a string library".
| drnick1 wrote:
| With LLMs becoming so good at coding, "just never make
| any mistake" is also becoming easier. I usually write my
| own code because I don't like the coding style of LLMs,
| but on more than one occasion now they have proven very
| useful as code reviewers and bug hunters.
| flohofwoe wrote:
| I bet that C won't just be around for legacy projects, but
| also for writing new code for at least the next 30 years.
| krapp wrote:
| C will end when our entire technological civilization
| collapses and has to start over from scratch and even then
| after a century of progress they will invent C again.
| Ar-Curunir wrote:
| Hopefully not. C is a bad language even for the standard
| of the times it was invented in.
| VBprogrammer wrote:
| I haven't ever had to do anything serious in C but it's
| hard to imagine getting it 100% right.
|
| A while back I wrote some C code to do the "short-bread"
| problem (it's a bit of a tradition at work to give it to
| people as their first task, though in Python it's a lot
| easier). Implementing a deque using all of the modern
| guard rails and a single file unit test framework still
| took me _a lot_ of attempts.
| flohofwoe wrote:
| C isn't a bad language per-se, it just doesn't have an
| opinion on most things and I think that's exactly the
| reason why it survived many higher level (and more
| opinionated) languages that also already existed when C
| was created.
| uecker wrote:
| This is exactly right. The trend is towards comprehensive
| programming frameworks for convenient programming with
| batteries included. I hope this trend dies and we focus
| more on integration into the overall ecosystem again.
| baq wrote:
| C was great... for the PDP-11.
|
| Nowadays, not so much. Computers are multiple orders of
| magnitude faster, have multiple orders of magnitude more
| memory and storage and do things multiple orders of
| magnitude more complex than they used to. Portable
| assembly still has its uses obviously, but
| safer/easier/faster alternatives exist in all its niches.
| flohofwoe wrote:
| > Portable assembly still has its uses obviously
|
| C is much closer to any other high level language than it
| is to assembly. 'Portable assembly' might have been true
| with trivial C compilers of the 70s and 80s, but not with
| compilers like gcc or clang.
| drnick1 wrote:
| > Computers are multiple orders of magnitude faster, have
| multiple orders of magnitude more memory and storage
|
| And C is still the best way to talk to the hardware in a
| portable way.
| GhosT078 wrote:
| In my timeline, something 10x better than Rust came along in
| 1995.
| 100721 wrote:
| Would you mind elaborating...?
| everythingctl wrote:
| I'd guess that's a reference to Ada 95.
| GhosT078 wrote:
| Yes
| GhosT078 wrote:
| Sane, easily readable syntax and expressive semantics.
| Easy to learn. Very scalable. Suitability, by design, for
| low level systems programming, including
| microcontrollers. Suitability, by design, for large,
| complex real-time applications. Easy to interface with C
| and other languages. Available as part of GCC. Stable and
| ongoing language evolution.
| antonvs wrote:
| Manual memory management for anything beyond RAII.
| speed_spread wrote:
| Java? Delphi? Better at what?
| mamcx wrote:
| yeah, this is the actual good mindset.
|
| C has never been a particularly good language, and is so
| _good_ that _finally_ (with tons of pushbacks!) there is an
| alternative that make the case so strong that is at least
| considered the possibility that will come the _very_ happy
| day where C will be our past.
|
| The only, true, real blocker is that C _is the ABI_. But if
| we consider the possibility that C can AND should be the
| past, then the C Abi can finally adds sophisticated things
| like Strings and such, and maybe dreaming, algebraic types
| (ie: the C will be improved with the required features so it
| can evolve the ABI, but not because will be a good language
| for write it (manually) on it).
|
| And to reiterate: C _should_ finally be a real assembly
| language, something we not need to worry about.
| biomechanica wrote:
| > And to reiterate: C should finally be a real assembly
| language, something we not need to worry about.
|
| Assembly is used quite a lot and if you're a programmer
| Assembly is very valuable to know _at least_ how to
| understand it.
|
| I disagree, also, that C should go away. Saying it was
| never a good language is a bit harsh. It's a great
| language. One that industries are built on. I'd rather
| read/write C code than, say, Rust.
|
| Edit: There are, of course, languages coming up that can
| absolutely compete with C. Zig could be one when it's
| mature, for instance.
| iberator wrote:
| COBOL is actively developed and maintained. It's far from
| being dead. Its working flawlessly and will be for the next
| few decades :)
|
| I bet you never wrote single program in Cobol...
| mustache_kimono wrote:
| > COBOL is actively developed and maintained. It's far from
| being dead.
|
| Who said it was dead? I was clear that I thought it was
| very much undead, like a zombie.
| testdelacc1 wrote:
| Neither needs to outlive the other to be individually useful.
|
| The way I see it, the longer something is actively used, the
| greater the chance it's going to stick around. I'm bullish on
| rust but I'm equally bullish that C will last a long, long
| time.
|
| But it's not an either-or here. Both are good at certain things
| and can coexist. Like they're coexisting in the Linux kernel
| for example.
| gritzko wrote:
| Correct me if I am wrong, but C is the "greatest common
| denominator" for several decades already. Java, .NET, go, Rust
| are very much ecosystems-in-themselves. From the practical
| standpoint, they can not use each other's code, but they all
| can use C libs.
| flohofwoe wrote:
| Technically it's only the C API that's important, the
| implementation behind the C API can be written in any
| language. The downside is though that you still need a
| language toolchains X, Y, Z to compile the implementations.
| Transpiling everything to C removes that one dimension from
| the build process.
| VBprogrammer wrote:
| Zig has been in the news a lot recently but I haven't
| explored it much other than a few tech talks which seemed
| interesting.
|
| I wonder if this is it's killer feature - compatibility
| with the C ABI.
| flohofwoe wrote:
| > compatibility with the C ABI
|
| Almost all non-C language offer that feature. The
| additional thing of the Zig toolchain is that it can also
| _compile_ C /C++/ObjC projects without requiring a
| separate compiler toolchain, e.g. the Zig compiler
| toolchain is also a complete C/C++ compiler toolchain.
| VBprogrammer wrote:
| Almost all languages provide a method of calling C
| generated code for sure. But, as I understand it, this is
| usually a more tortuous path than straight ABI
| compatibility.
| ahartmetz wrote:
| Unless something similar to but better than Rust comes along
| soon, I expect both Rust and C to live "forever".
| sakompella wrote:
| Unfortunately, I really doubt long rust's "forever" will last
| in the wake of the `time` crate controversy. I can't see like
| a lot of good options in that place from the perspectives of
| the rust-std maintainers, but it might've just been worth it
| to wait for a new edition or similar.
| antonvs wrote:
| Why do you believe that's going to have some sort of
| lasting effect on Rust?
| Wowfunhappy wrote:
| It also feels to me like Rust is trying to replace C++ more-so
| than C.
| drnick1 wrote:
| There SO MUCH C++ out there that it won't ever be replaced.
| For one, Rust (or plain C) isn't a good choice for big
| applications (GUI, video games, web browsers, and many
| others) where classic OOP is so useful.
| Wowfunhappy wrote:
| Maybe "replace" was the wrong word. What I mean is that
| Rust is "a better C++" to a much greater extent than it is
| "a better C".
| BobbyTables2 wrote:
| Not saying it isn't neat, but WHY?
|
| Seems like the kind of thing that happens before a language is
| natively supported by a compiler.
| viraptor wrote:
| If only the article started with an explanation...
| thrance wrote:
| There's literally a section named "Why?" in the article.
| procaryote wrote:
| They want to use rust but can't, because they need C
| compatibility, e.g. because they're providing a library or
| wants to support platforms that rust don't.
|
| It's at least a less bad idea than I expected originally - I've
| mainly seen people try to use transpilers to sneakily start
| using the language they prefer as part of a larger code base,
| with all the obvious problems.
|
| It's still not great as you now have an additional translation
| step to deal with. You will at some point need to look for bugs
| in the generated C layer, which will really suck. Users of the
| C library can't read your source to understand what it does
| internally without an extra step to figure out what rust code
| the thing they use corresponds to, etc.
|
| If you want to provide a C library, write C. If rust isn't an
| option because it doesn't work for your customers who use C,
| don't use rust.
| zozbot234 wrote:
| You can write a C-compatible binary library in Rust (see the
| cdylib target) and cbindgen can then generate proper C header
| files for any C-ABI interfaces exposed in Rust code. A full
| Rust-to-C compiler should only be needed for targets that
| have some C compiler available but are just not supported by
| the current Rust toolchain.
| flohofwoe wrote:
| If you have an existing build system for your C project,
| you sure as hell don't want to bring another compiler
| toolchain (like Rust) into the mix.
| zozbot234 wrote:
| You'd need the Rust compiler toolchain anyway, just to do
| the Rust-to-C conversion step instead of compiling to a
| binary library? What would be the point? The C ABI is
| quite compatible across toolchains.
| flohofwoe wrote:
| > You'd need the Rust compiler toolchain anyway, just to
| do the Rust-to-C conversion step instead of compiling to
| a binary library?
|
| The Rust-to-C conversion would be done by the Rust
| library author (or more likely, some automated CI
| process) to create a C source code distribution of the
| Rust library.
| drwu wrote:
| Rust compiler can be easily bootstrapped.
| nutjob2 wrote:
| Another Rust compiler with a C backend:
|
| https://github.com/thepowersgang/mrustc
| ValtteriL wrote:
| Github: https://github.com/AeneasVerif/eurydice
| opem wrote:
| Cool, loved this! These tools would be needed in the near future
| to manage the tech debt safe rust is compounding.
| bloppe wrote:
| Rust compiles to LLVM IR. I'm pretty surprised that building this
| transpiler was considered a better use of time than writing an
| LLVM backend for whatever "weird embedded target" might need
| this.
| aw1621107 wrote:
| In fact there used to be a C backend for LLVM, but it was
| removed in LLVM 3.1 [0]. JuliaHub has resurrected it as a
| third-party backend [1], though I have no idea if there is any
| interest in upstreaming the work from either end.
|
| [0]: https://releases.llvm.org/3.1/docs/ReleaseNotes.html
|
| [1]: https://releases.llvm.org/3.1/docs/ReleaseNotes.html
| fithisux wrote:
| The refs are duplicated.
| aw1621107 wrote:
| Ack, my bad. Can't edit the comment any more,
| unfortunately. Second ref is supposed to be to
| https://github.com/JuliaHubOSS/llvm-cbe
| fithisux wrote:
| Thanks
| rcxdude wrote:
| This would cover many different weird embedded targets, and a
| lot of those targets can be an utter pain to target with a
| compiler.
| Wuzado wrote:
| Sometimes you may need to deal with odd proprietary processors
| with limited and flawed knowledge about them.
|
| For example, in the 37c3 talk "Breaking "DRM" in Polish trains"
| by the folks from Dragon Sector (I highly recommend watching
| it), they needed to reverse-engineer Tricore binaries, however
| they found the Ghidra implementation had bugs.
|
| As for the PLCs, the IEC 61131-3 functional block diagrams
| transpile to C code which then compiles to Tricore binaries
| using an obscure GCC fork. Not saying that anyone would want to
| write Rust code for PLCs, but this is not uncommon in the world
| of embedded.
| mistrial9 wrote:
| .. there is some humor in the string
|
| "Breaking "DRM" in Polish trains"
| iberator wrote:
| Why?
| SkiFire13 wrote:
| Rustc supports backends other than LLVM btw
| forgotpwd16 wrote:
| And someone has made
| (https://github.com/FractalFir/rustc_codegen_clr) a backend
| targeting C (alongside .NET/CIL).
| flohofwoe wrote:
| If you write a library in Rust and want to make that library
| available to other language ecosystems, not requiring a Rust
| compiler toolchain for using the library is a pretty big plus -
| instead create a C source distribution of the library,
| basically using C as the cross-platform intermediate format.
| torginus wrote:
| There are many kinds of IRs in compilers - I'm not familiar
| with how Rust works, but for example GCC has an intermediate
| representation called GENERIC, which is a C-like language that
| preserves the scoping and loops and branches of the inputted C
| code.
|
| Lower level representations also exist - since C has goto, you
| can pretty much turn any SSA IR to C, but the end result won't
| be readable.
| NooneAtAll3 wrote:
| I have never seen any guides or blogs about writing LLVM
| backend
|
| and considering how long compiling LLVM takes... it's
| reasonable to go for other options
| Bratmon wrote:
| I think you may not be familiar with how embedded development
| works.
|
| Most teams who write code for embedded devices (especially the
| weird devices at issue here) don't have the hardware knowledge,
| time, or contractual ability to write their own compiler
| backend. They're almost always stuck with the compiler the
| manufacturer decided to give them.
| aw1621107 wrote:
| I think the approach would not be to alter the manufacturer's
| compiler directly, but to run your Rust code through a
| separate Rust-to-C compiler then feed that output into the
| compiler the manufacturer gave you.
| bloppe wrote:
| You're right. But I'm also surprised any device manufacturer
| would think it's a better use of _their_ time to ship a
| bespoke C compiler rather than an LLVM backend that would
| allow a lot more languages to be built against their ISA,
| making it more valuable.
|
| But ya, I believe this project exists for a meaningful
| purpose, I'm just surprised.
| hexo wrote:
| So this means I can completely get rid of rust. Yay
| pankajdoharey wrote:
| In a world where Crabs are trying to rewrite everything in their
| favourite Crab Speak its nice to see the Reverse. I wonder if it
| coulkd be used to translate Rust compiler itself to C :-D
| Y_Y wrote:
| https://github.com/Rust-GCC/gccrs/tree/master/gcc/rust
|
| There's a Rust compiler in C++ in case that's any good to you
| Aissen wrote:
| > for instance, Rust panics on integer overflow
|
| By default, this is only in debug mode. I recently forgot to add
| it to release mode on a project, and was surprised when I broke
| the CI (tests run in debug, I only tested in release mode).
| IshKebab wrote:
| The perfect headline to bring the anti-Rust luddites out of the
| woodwork...
| exDM69 wrote:
| The project itself is cool and useful but the motivating example
| of crypto (primitives?) isn't great.
|
| Cryptography is already difficult to write in high level
| languages without introducing side channels via timing, branch
| predictor, caches etc.
|
| Cryptography while going through two high level compilers,
| especially when the code was not designed and written to do so is
| an exercise fraught with peril.
|
| Tbf, this is just nitpicking about the article, not the project
| itself
| the8472 wrote:
| It's not possible to correctly implement any cryptographic
| algorithms in any high-level language with an optimizing
| backend where timing is not considered an observable/perserved
| property. Currently this includes anything backed by LLVM or
| GCC, though there's a proposal to introduce such guarantees
| through a new builtin in LLVM https://github.com/llvm/llvm-
| project/pull/166702 though those could still be broken by post-
| build optimizers, like wasm.
| d-lisp wrote:
| When you think about it, Perseus did use Medusa's head to
| transform things into stone.
|
| In fact he turned king Polydectes and all of his followers into
| stone when he went back to Sephiros.
|
| Perseus defeated Medusa by not looking at her in the eyes.
|
| Rust in a sense, allow you to solve problems without having to
| look directly at memory unsafe behavior.
|
| I would have called this project "Medusa".
| jll29 wrote:
| The original author of the post also
|
| - has designed the Mezzo programming language in his Ph.D. thesis
| and
|
| - has worked on generating user-friendly C automatically. Most
| tools that generate C output pretty unreadable/unmaintainable
| code that you won't like to maintain, so this is a much under-
| researched topic.
| Surac wrote:
| I was always told rust uses llvm tokens not produceable by c code
| to do its magic. Was I informed wrong?
| mmastrac wrote:
| There are multiple stages of IR in the compiler, basically
| SAI_Peregrinus wrote:
| You probably misunderstood. C can represent any program's
| semantics, since it's Turing-complete (modulo finite memory). C
| can't encode the lifetimes Rust uses, but those get erased
| during compilation to MIR. This takes MIR from rustc (where
| borrow checking has been completed and lifetime annotations
| erased) and outputs C with the same semantics. LLVM doesn't use
| tokens not produceable by C, but rustc does.
| Grikbdl wrote:
| I think it's a reference to certain optimizations possible
| due to aliasing rules in Rust that are not possible (or maybe
| only "not straight forward", I'm not sure) in C. So a
| transpiled program while keeping its semantics might not
| still compile to equally optimized assembly.
| SAI_Peregrinus wrote:
| IIRC C can do the same things with correct usage of
| `restrict`, but that's extremely difficult by hand. So
| difficult that LLVM's `restrict` support was very buggy
| when Rust first started using the capabilities. Those bugs
| got fixed, but it's still impractical to use in handwritten
| C.
___________________________________________________________________
(page generated 2025-12-07 23:01 UTC)