rlua -- High level bindings between Rust and Lua

Related tags

Miscellaneous rlua

rlua -- High level bindings between Rust and Lua

Build Status Latest Version API Documentation

Guided Tour

This library is a high level interface between Rust and Lua. Its goal is to be an easy to use, practical, flexible, and safe API between Rust and Lua.

rlua is NOT designed to be a perfect zero cost wrapper over the Lua C API, because such a wrapper cannot maintain the safety guarantees that rlua is designed to have. Every place where the Lua C API may trigger an error longjmp in any way is protected by lua_pcall, and the user of the library is protected from directly interacting with unsafe things like the Lua stack, and there is overhead associated with this safety. However, performance is a focus of the library to the extent possible while maintaining safety, so if you encounter something that is egregiously worse than using the Lua C API directly, or simply something you feel could perform better, feel free to file a bug report.

API stability

Currently, this library follows a pre-1.0 semver, so all API changes should be accompanied by 0.x version bumps.

The new 0.16 release has a particularly large amount of API breakage which was required to fix several long-standing limitations and bugs. The biggest change by far is that most API usage now takes place through Lua::context callbacks rather than directly on the main Lua state object. See CHANGELOG.md for information about other API changes, and also see the guided tour for an example of using the new Context API.

Safety and Panics

The goal of this library is complete safety: it should not be possible to cause undefined behavior with the safe API, even in edge cases. Unsoundness is considered the most serious kind of bug, so if you find the ability to cause UB with this API without unsafe, please file a bug report.

NOTE: There are some Lua stdlib functions which are currently not wrapped or behind an unsafe boundary and can be used by scripts to cause memory unsafety, please see this issue for more details.

Another goal of this library is complete protection from panics: currently, it should not be possible for a script to trigger a panic. There ARE however several internal panics in the library, but triggering them is considered a bug. If you find a way to trigger these internal panics, please file a bug report.

Yet another goal of the library is to, in all cases, safely handle panics that are generated inside Rust callbacks. Panic unwinds in Rust callbacks should currently be handled correctly -- the unwind is caught and carried across the Lua API boundary as a regular Lua error in a way that prevents Lua from catching it. This is done by overriding the normal Lua 'pcall' and 'xpcall' functions with custom versions that cannot catch errors that are actually from Rust panics, and by handling panic errors on the receiving Rust side by resuming the panic.

rlua should also be panic safe in another way as well, which is that any Lua instances or handles should remain usable after a user generated panic, and such panics should not break internal invariants or leak Lua stack space. This is mostly important to safely use rlua types in Drop impls, as you should not be using panics for general error handling.

In summary, here is a list of rlua behaviors that should be considered a bug. If you encounter them, a bug report would be very welcome:

  • If you can cause UB with rlua without typing the word "unsafe", this is a bug.
  • If your program panics with a message that contains the string "rlua internal error", this is a bug.
  • The above is true even for the internal panic about running out of stack space! There are a few ways to generate normal script errors by running out of stack, but if you encounter a panic based on running out of stack, this is a bug.
  • When the internal version of Lua is built using the cc crate, and cfg!(debug_assertions) is true, Lua is built with the LUA_USE_APICHECK define set. Any abort caused by this internal Lua API checking is definitely a bug, and is likely to be a soundness bug because without LUA_USE_APICHECK it would likely instead be UB.
  • Lua C API errors are handled by lonjmp. All instances where the Lua C API would otherwise longjmp over calling stack frames should be guarded against, except in internal callbacks where this is intentional. If you detect that rlua is triggering a longjmp over your Rust stack frames, this is a bug!
  • If you can somehow handle a panic triggered from a Rust callback in Lua, this is a bug.
  • If you detect that, after catching a panic or during a Drop triggered from a panic, a Lua or handle method is triggering other bugs or there is a Lua stack space leak, this is a bug. rlua instances are supposed to remain fully usable in the face of user generated panics. This guarantee does not extend to panics marked with "rlua internal error" simply because that is already indicative of a separate bug.

Sandboxing and Untrusted Scripts

The API now contains the pieces necessary to implement simple, limited "sandboxing" of Lua scripts by controlling their environment, limiting their allotted VM instructions, and limiting the amount of memory they may allocate.

These features deserve a few words of warning: Do not use them to run untrusted scripts unless you really Know What You Are Doing (tm) (and even then, you probably should not do this).

First, this library contains a huge amount of unsafe code, and I currently would not trust it in a truly security sensitive context. There are almost certainly bugs still lurking in this library! It is surprisingly, fiendishly difficult to use the Lua C API without the potential for unsafety.

Second, properly sandboxing Lua scripts can be quite difficult, much of the stdlib is unsafe, and sometimes in surprising ways. Some information on this can be found here.

Third, PUC-Rio Lua is a C library not really designed to be used with untrusted scripts. Please understand that though PUC-Rio Lua is an extremely well written language runtime, it is still quite a lot of C code, and it is not commonly used with truly malicious scripts. Take a look here and count how many bugs resulted in memory unsafety in the interpreter. Another small example: did you know there is a way to attack Lua tables to cause linear complexity in the table length operator? That this still counts as one VM instruction?

Fourth, if you provide a callback API to scripts, it can be very difficult to secure that API. Do all of your API functions have some maximum runtime? Do any of your API functions allow the script to allocate via Rust? Are there limits on how much they can allocate this way? All callback functions still count as a single VM instruction!

In any case, sandboxing in this way may still be useful to protect against buggy (but non-malicious) scripts, and may even serve as a single layer of a larger security strategy, but please think twice before relying on this to protect you from untrusted Lua code.


This project is licensed under the MIT license

  • Support for hooks (viewing only)

    Support for hooks (viewing only)

    This PR adds three new functions and a few other types to safely wrap the lua_sethook function, as suggested by the issue https://github.com/kyren/rlua/issues/81.

    This is my best attempt to make it possible to consult information for debugging purposes and to control script execution.

    These functions have been written:

    • set_hook and set_mut_hook: Sets a function to be called when the hook is raised. It gets the new Debug struct containing information related to the code and function (depending on the hook mask)
    • remove_hook: Removes the hook previously set

    A few new types such as Debug and HookOptions, written inside a new module, are used as parameters to those functions above. That module also contains a procedure given to lua_sethook used to call the Rust callback safely.

    I regard this change as safe since it does not expose functions that changes the Lua stack or anything else (other than using the Lua structure itself). Moreover, since the hook can return a Result, it can terminate the execution of a script, as shown in a test, by returning the error back to the caller of exec and such. This satisfies the desire of the author as noted in the README.

    Anyone is welcome to comment or suggest changes to make on my PR, since I did it without knowing too much about Lua's internal workings. I have not changed the README or version; I leave this to rlua's author discretion.

    Thank you.

    opened by lemarcuspoilus 56
  • rlua is looking for maintainers!

    rlua is looking for maintainers!

    Copied from a reddit discussion here:

    I don't actually use Lua for anything currently, and I also don't have much interest in returning to Lua in the future. As such, my Lua related crates rlua (and also luster, but that's much less important) are not receiving much attention currently.

    That's a real shame, and I'd like to help at least rlua not become abandoned. It needs some work done to it, none of which is terribly complex but I just don't have the time or proper motivation to be the one to do it. Also, I don't actually even think I should be the one to do it, as it's very hard to make good APIs when you don't use your own API.

    I'd be happy to guide people through my ideas for rlua and help especially with reviewing PRs for unsoundness, but there is quite a lot of stuff that needs doing in the pretty near term. The internals of rlua are pretty hairy, which is why I don't expect anybody who wants to take up the mantle to go it completely alone, I'll happily be around to help with the hard parts. What it needs though is better leadership and organization skills than I have or at least have to spare currently.

    opened by kyren 43
  • Current __gc logic for userdata is unsound

    Current __gc logic for userdata is unsound

    The manual states:

    Moreover, if the finalizer marks a finalizing object for finalization again, its finalizer will be called again in the next cycle where the object is unreachable.

    This means that a destructor assigned to the __gc metamethod might be run multiple times on the same userdata. Inside fn destructor, rlua currently just does this:

            let obj = &mut *(ffi::lua_touserdata(state, 1) as *mut T);
            mem::replace(obj, mem::uninitialized());

    ~~If one figures out a way to resurrect the userdata object from within drop, this leads to a double free. However, I am not sure if this is possible, since all userdata must outlive 'static.~~

    ~~If this is by design, it would be helpful to document that. In general, rluas internals are barely documented which makes it hard to understand and debug stuff like #18.~~

    EDIT: See comment below for use-after-free demonstration

    opened by jonas-schievink 35
  • need a uniqe coroutine id avaiable in rust

    need a uniqe coroutine id avaiable in rust

    When i create a lua thread(coroutine) from rust, it will quite useful to have a unique id available in thread struct to refer to thread object. We may follow below stack overflow link to decide what can be used as that unique id. https://stackoverflow.com/questions/18912240/how-do-i-identify-on-which-thread-a-lua-script-is-running

    opened by surajprak 31
  • How to store a Lua function in UserData

    How to store a Lua function in UserData

    I need to store a user-provided Lua function in a struct that implements UserData. I tried using UserDataMethods to add a method that takes in a function and stores it but I keep running into lifetime errors.

    rlua::Lua is expected to live for the entirety of the program (and in fact I put it in a lazy_static! so that its address is always stable), but I can't find a way to indicate in the custom user data method that rlua::Lua will be 'static and there's no way for me to convince it that the anonymous 'lua lifetime for the passed in rlua::Lua reference will live longer than the reference I store in the UserData.

    Here's a minimized example of the issue I'm running into:

    use rlua;
    // How long the function lives, should be == 'lua
    struct MyUserData<'function> { 
        function: Option<rlua::Function<'function>>
    // HAS to be static, due to `UserData` requirements...
    impl UserData for MyUserData<'static> 
        fn add_methods(methods: &mut rlua::UserDataMethods<Self>) {
            methods.add_method_mut("test", test_function);
    // lifetime issue occurs in this function
    // is there some way for me to prove that `this` lives as long as `lua`??
    fn test_function(lua: &rlua::Lua, this: &mut MyUserData, func: rlua::Function)
                            -> rlua::Result<()> {
        this.function = Some(func);
    fn main() {}
    opened by Timidger 30
  • Segfault in LuaTable::set

    Segfault in LuaTable::set

    After a long debugging session, I've noticed that cargo test --release fails with a segfault on the current nightly.

    This might as well be a regression of the compiler, I'm not yet sure.

    opened by jonas-schievink 26
  • Unbounded callback lifetimes cause rlua to be unsound

    Unbounded callback lifetimes cause rlua to be unsound

    I'm going to write a very long explanation of this bug, because the root issue here is something that has come up again and again, and I need to document exactly what's going on.

    tl;dr I might have an easy fix, but the internal types for callbacks inside rlua are problematic and they probably should change before 1.0. (Edit: I don't have an easy fix D:)

    So, the internal type of callbacks in rlua is (basically) this:

    type Callback<'cb> = Box<Fn(&'cb Lua, MultiValue<'cb>) -> Result<MultiValue<'cb> + Send>

    There are a few different ways to create rust callbacks in rlua, but all of the APIs are basically variations on Lua::create_function:

    pub fn create_function<'lua, 'cb, A, R, F>(&'lua self, f: F) -> Result<Function<'lua>>
        A: FromLuaMulti<'cb>,
        R: ToLuaMulti<'cb>,
        F: Fn(&'cb Lua, A) -> Result<R> + 'static + Send,

    These functions take an F and produce the internal Callback type, which is then later used to create a Lua callback with lua_pushcclosure, but that part isn't terribly important. What is important here is the 'cb lifetime: all of the APIs that look like this have the 'cb lifetime as an unbounded user chosen lifetime, and this is deeply, deeply wrong. This has always been wrong, and this has been wrong since the very first versions of this crate.

    Here's what the type of the internal callback should be:

    type Callback = Box<for<'cb> Fn(&'cb Lua, MultiValue<'cb>) -> Result<MultiValue<'cb>> + Send>

    which is to say that the internal callback should be a function that given any 'lua lifetime, it can take a Lua ref and arguments with the same 'lua lifetime and produce results with that same 'lua lifetime. This is the actual, logical requirement that we want to express on the callback, and though we can make this type just fine, problems start when we want to make our callback API. Let's see how we might change our create_function type to allow for the correct callback type:

    pub fn create_function<'lua, A, R, F>(&'lua self, f: F) -> Result<Function<'lua>>
        A: for<'cb> FromLuaMulti<'cb>,
        R: for<'cb> ToLuaMulti<'cb>,
        F: for<'cb> Fn(&'cb Lua, A) -> Result<R> + 'static + Send,

    Except, this will never work, because we have three separate for<'cb> HRTBs and there is no way to tell the rust compiler that we need to universally quantify all three trait bounds over a single lifetime.

    What's especially frustrating is that it's actually totally possible to write the code that produces the correct callback type, but it's not currently possible to put that code into a function and name its type signature; observe.

    You can see me struggling with this problem in a very old reddit post here. To proceed with the API and get around this otherwise very tricky or impossible to solve limitation, I picked an API that conveniently "lied" about the callback lifetimes, and I believed this was safe because all callbacks at the time were 'static anyway. Well, honestly I had a pretty poor understanding of the borrow checker at the time and I was very unsure of everything, but later on I became slightly more confident that my lie based interface was safe due to the 'static callback requirement. I now know this is wrong, and should have realized this sooner.

    I lied a bit above, the real callback type inside rlua is actually not what I said above, there is actually a second lifetime parameter to make the callback itself non-'static for use in Lua::scope, so the real callback type is actually this:

    type Callback<'cb, 'a> = Box<Fn(&'cb Lua, MultiValue<'cb>) -> Result<MultiValue<'cb>> + Send + 'a>

    This is to facilitate the Scope callbacks having a non-'static lifetime, which if you understand how the argument lifetimes are lying there, you know this is obviously a problem. At the time I initially made the Scope interface I didn't really fully understand the implications of the misleading callback types that I was using. I later found out via #82 that the initial interface that I had written was of course unsound, and it was only after fixing that issue that I more fully understood the problem.

    From a certain perspective, the misleading callback types are the root cause of #82, because the callback type requires this user chosen, unbounded 'cb lifetime and that makes writing a sound interface extremely difficult and easy to get wrong. I believe the solution for #82 is correct, but it is extremely delicate and intricate and confusing, and this is the LAST property that you want when writing rust code with unsafe.

    So the reason that I'm writing about this problem now is not actually due to #82. Instead it is because I had a minor panic attack today over the following thought: "what if you convinced the borrow checker to pick 'static as the 'cb lifetime in rlua callbacks?".

    Well, it turns out you can totally do this, and it's obvious that you can do this and I should have realized this sooner. Observe this monstrosity:

    extern crate rlua;
    use std::cell::RefCell;
    use rlua::{Lua, Table};
    fn main() {
        thread_local! {
            static BAD_TIME: RefCell<Option<Table<'static>>> = RefCell::new(None);
        let lua = Lua::new();
        lua.create_function(|_, table: Table| {
            BAD_TIME.with(|bt| {
                *bt.borrow_mut() = Some(table);
        .call::<_, ()>(lua.create_table().unwrap())
        // In debug, this will panic with a reference leak before getting to the next part but
        // it segfaults anyway.
        BAD_TIME.with(|bt| {
                "you're gonna have a bad time: {}",

    So the proper fix is honestly the same as the proper fix for #82, which is to fix the callback types, and thus also fix the callback API. However, without ATCs, it appears that the only way that I can do so is either macros (to write the voldemort function who's type I can't name), or possibly some other trait trick I'm not aware of, or possibly redesign ToLua / FromLua to not require ATCs, I'm not sure.

    In the meantime, there's a hopefully simple fix for this issue, but I need to test it out first, and I'll be back in a moment.

    opened by kyren 22
  • feature: lua bindgen

    feature: lua bindgen

    this moves the sys binding to another package and lets bindgen produce the bindings. There are some technical problems with versioning I haven't quite figured out and the bindings themselves are mostly correct I just have to re-import them and do some casting to correct some of the constant types. At the moment this is configured through an environment variable LUA_VERSION.

    I do end up losing functionality i.e I got rid of a way to configure the build through dpkg I think that can easily be fixed just haven't figured out how the build would work though? is it possible to pass environment flags to the sys package?

    I was looking at this but it seems to only be available in a nightly build of cargo. https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#configurable-env

    LUA_VERSION=v5.4.3 cargo build
    opened by pollend 17
  • Don't let Lua code cause panics or aborts

    Don't let Lua code cause panics or aborts

    This is a tracking issue for the remaining cases where Lua code can cause a Rust panic or a direct abort. This is generally unwanted, because untrusted Lua code should not be able to abort the Rust program. Although panics can be caught on the Rust-side, it is intended that all errors caused by Lua are propagated using LuaResult.

    Note that fixing these issues will still not make it advisable to run arbitrary untrusted Lua code. Proper sandboxing support and execution limits need to be exposed first.

    • [x] Accessing resurrected UserData directly causes a panic. Instead, a Lua error should be raised. This error can be caught by Lua (this isn't very useful, but also not a big problem) or will propagate to the Rust code that caused the Lua code to run.
    • [x] Exceeding the stack size with Rust callbacks will lead either to an assertion failure (which is an abort) in Lua or to a panic. rlua should automatically provide and enforce a recursion limit, raising a Lua error when hit.
    • [x] According to the readme: There are currently no checks on argument sizes. An abort can be caused by passing too large Variadics or MultiValues. When Rust calls a function with too many arguments, an Error should be directly returned. When Lua calls a Rust callback with too many arguments, the Lua runtime should already handle this. However, a Rust callback can also return too many values (Lua "only" guarantees that at least 1000 values can be returned). This can be handled by raising a Lua error. Alternatively, we can define this as a bug on the Rust side and cause a panic. This can lead to subtle bugs, however, when the number of values depends on the inputs from Lua or is otherwise unclear.
    • [x] Errors in __gc cause an abort. Raising a Lua error from here is unsafe, so it is caught and the program is aborted. This might be a reasonable default behaviour in some cases, but it would be nice if a user-defined callback could be provided.
    • [x] Allocation failure causes an abort. While this matches Rust's behaviour, a way to limit the amount of memory used by Lua code is essential to be able to run untrusted code.

    I hope these are all cases. If not, feel free to comment/edit, of course.

    opened by jonas-schievink 17
  • debug library not included

    debug library not included

    Hey there,

    The awesome lua library (which I'm trying to run with these bindings) makes great use of the debug functionality of Lua (specifically debug.traceback), but it's not included in these bindings. I could make it myself, but I just wanted to double check to see why it's not included.

    opened by Timidger 16
  • Why is Lua not Send?

    Why is Lua not Send?

    I believe wrapping Lua in Arc<Mutex<...>> should allow passing it to other threads and synchronized access?

    Right now it's this:

    error[E0277]: the trait bound `*mut rlua::ffi::lua_State: std::marker::Send` is not satisfied in `rlua::Lua`
      --> src/main.rs:29:29
    29 |     let event_loop_thread = thread::spawn({
       |                             ^^^^^^^^^^^^^ `*mut rlua::ffi::lua_State` cannot be sent between threads safely
       = help: within `rlua::Lua`, the trait `std::marker::Send` is not implemented for `*mut rlua::ffi::lua_State`
       = note: required because it appears within the type `rlua::Lua`
       = note: required because of the requirements on the impl of `std::marker::Send` for `std::sync::Mutex<rlua::Lua>`
       = note: required because of the requirements on the impl of `std::marker::Send` for `std::sync::Arc<std::sync::Mutex<rlua::Lua>>`
       = note: required because it appears within the type `[[email protected]/main.rs:32:9: 55:10 lua:std::sync::Arc<std::sync::Mutex<rlua::Lua>>, barrier:std::sync::Arc<std::sync::Barrier>]`
       = note: required by `std::thread::spawn`
    opened by mkpankov 16
  • perf: faster HashMap with TypeId keys

    perf: faster HashMap with TypeId keys

    TypeIds are already hashes from the compiler, so they don't need to be hashed again. I've added a dummy hasher which just passes the TypeId through without modifying it.

    For example, the tracing-subscriber crate does the same thing: https://github.com/tokio-rs/tracing/blob/3517552c319a22c108d423ca9a1675e632f616a3/tracing-subscriber/src/registry/extensions.rs#L12-L34

    opened by Purpzie 4
  • Missing API

    Missing API

    I have a method named rgba on a struct which I'd like to map to a UserData. The return type of the method is Option<(u8, u8, u8, u8)>. Unfortunately rule has no built-in ToLuaMulti implemented for an optional tuple. The expected lua result is nil for None and 4 integer returns if Some.

    Can the API be extended to allow sending optional tuples to lua?

    opened by Yuri6037 1
  • Potential HUGE loss in performance

    Potential HUGE loss in performance

    I'm looking into using this library in a 3D engine project. I'm hitting a HUGE performance wall with this library that the C API would never get: all UserData values must be cloned in order to read them from Lua! This means that every time you map a function which takes this and another instance of itself you must allocate again even if the type is already allocated and managed by Lua.

    It should be possible to accept references to user data types instead of cloning all the time.

    opened by Yuri6037 16
  • os.setlocale() may be unsafe

    os.setlocale() may be unsafe

    os.setlocale() may have thread safety issues and hence be memory-unsafe to call from Lua. This needs a bit of research to decide on the best option (or possibly just remove them by default with an InitFlag).

    opened by jugglerchris 0
  • Handle os.date unsafety in Lua 5.1

    Handle os.date unsafety in Lua 5.1

    There is a known unsafety with os.date() in Lua 5.1 (because format strings are passed straight to the C strftime). http://lua-users.org/lists/lua-l/2008-09/msg00146.html Lua 5.2+ check the strings before passing them to strftime. rlua should do something similar for Lua 5.1 (perhaps replace os.date() with one which uses a Rust library such as time or chrono).

    bug unsound :boom: good first issue 
    opened by jugglerchris 0
Amethyst Foundation
Non-Profit with focus on Rust and the Game Dev ecosystem.
Amethyst Foundation
A binding between C++11 and Lua language

lua-intf lua-intf is a binding between C++11 and Lua language, it provides three different set of API in one package: LuaBinding, Export C++ class or

Steve K. Chiu 406 Dec 5, 2022
An AI for playing NES Tetris at a high level. Based primarily on search & heuristic, with high quality board evaluation through value iteration.

StackRabbit An AI that plays NES Tetris at a high level. Primarily based on search & heuristic, with high-quality board eval through value iteration.

Greg Cannon 244 Jan 5, 2023
a one header library for creating Lua bindings to C++

Description A C++ library for generating Lua bindings. Supported features: functions, constructors, inheritance, member functions, properties, standar

null 76 Aug 20, 2022
A dependency free, embeddable debugger for Lua in a single file (.lua or .c)

debugger.lua A simple, embedabble debugger for Lua 5.x, and LuaJIT 2.x. debugger.lua is a simple, single file, pure Lua debugger that is easy to integ

Scott Lembcke 600 Dec 31, 2022
The Lua development repository, as seen by the Lua team. Mirrored irregularly

The Lua development repository, as seen by the Lua team. Mirrored irregularly

Lua 6.4k Jan 5, 2023
A water tank level sensor **Built With WisBlock** to detect overflow and low level conditions.

RAK12014 Laser TOF sensor coming soon WisBlock Watertank Level Sensor Watertank Overflow detection using the RAKwireless WisBlock modules. It implemen

Bernd Giesecke 3 Feb 3, 2022
This repository is used for automatic calibration between high resolution LiDAR and camera in targetless scenes.

livox_camera_calib livox_camera_calib is a robust, high accuracy extrinsic calibration tool between high resolution LiDAR (e.g. Livox) and camera in t

HKU-Mars-Lab 491 Dec 29, 2022
Program your micro-controllers in a fast and robust high-level language.

Toit language implementation This repository contains the Toit language implementation. It is fully open source and consists of the compiler, virtual

Toit language 988 Jan 4, 2023
DISLIN is a high-level plotting library developed by Helmut Michels at the Max Planck Institute.

Harbour bindings for DISLIN, is a high level library of subroutines and functions that display data graphically.

Rafał Jopek 2 Dec 10, 2021
NavMeshComponents - High Level API Components for Runtime NavMesh Building

Status of the project Development This project is now developed as part of the AI Navigation package. Please add that package to your project in order

Unity Technologies 2.7k Jan 8, 2023
A Visual Studio extension that provides enhanced support for editing High Level Shading Language (HLSL) files

HLSL Tools for Visual Studio This extension is for Visual Studio 2017 / 2019. Go here for the Visual Studio Code extension. HLSL Tools is a Visual Stu

Tim Jones 433 Dec 27, 2022
Backtrace support for Rust `no_std` and embedded programs.

mini-backtrace This crate provides backtrace support for no_std and embedded programs. This is done through by compiling LLVM's libunwind with certain

Amanieu d'Antras 27 Dec 18, 2022
Tests to check the determinism of the basic floating point arithmetic operations on different devices, using Unity and Rust.

This repo contains tests to check the determinism (consistency) of the basic floating point arithmetic operations (add, subtract, multiply, divide) on

Erik Roystan 9 Dec 20, 2022
C, C++, D, Fortran, Rust and Zig for your z80

z80 Babel: C, C++, D, Fortran, Rust and Zig for your z80 This is a proof of concept for a multi-language pipeline for the Z80 CPU, and its correspondi

Manuel Martinez Torres 15 Dec 23, 2022
Rust External Cheat

rust-external-cheat Rust External Cheat neden bu projedesiniz hemen anlatayım; daha type casting nedir bilmeyen pasterların pastelediği sourcedir. tam

Orçun 23 Jun 27, 2022
Just storing all my codes in Rust here (learning)

Rust-Dump I am learning Rust in 2021, and this will take some time. The end goal is to be able to understand the codebase of PopOS and contribute. I'l

Kushashwa Ravi Shrimali 3 Nov 3, 2021
Integration of Rust code with a C Kernel Module

Rust-Kernel-Mod Description Integration of Rust code with a C Kernel Module This project sets up a minimalistic Linux kernel module in C which it uses

Dylan Turner 1 Nov 1, 2021
udbg's windows driver written in rust

This is the code of windows driver used in udbg, it contains the basic function used in udbg's 'krnl' adaptor, such as memory read/write, and it integ

null 3 Nov 3, 2021
A kdmapper library for Rust

A kdmapper library for Rust Needed to integrate TheCruZ/kdmapper into one of my projects, so I made a library that will let me integrate kdmapper into my Rust code

Ryan McCrystal 10 Oct 2, 2022