Axivion: One Tool for Your Entire C/C++/Rust Codebase

In May of this year, Rust became an officially supported language in Axivion. It joins C, C++, C#, and CUDA C++ under the same static code analysis, architecture verification, and quality monitoring capabilities Axivion users already rely on.

This post is for teams that are introducing Rust into an existing C/C++ codebase and want to know what Axivion does for them in practice.

Mixed Codebases - The Situation Most Teams are in

Most teams adopting Rust are often managing a mixed codebase where Rust and C/C++ have to coexist for years.

The most common setup we’re seeing is new modules being written in Rust while large parts of the system stay in C and C++. And the two have to talk to each other across Foreign Function Interface (FFI) boundaries. This setup creates problems the Rust toolchain alone does not solve. They're the kind of defects that pile up in a hybrid codebase, and they're what Axivion is built to handle.

One Model for Every Language in Your Codebase

Axivion gives your engineering and quality teams one view of architecture, metrics, and code health across C, C++, C#, Rust, and CUDA C++ at the same time.

Architecture verification, static code analysis, and quality monitoring all work off the same model of your system, no matter which language a module happens to be in. Before, developers juggle separate reports per language — switching tools, manually correlating findings, and still potentially missing the bugs that live on the boundary between them. With Axivion, there's one dashboard: Rust, C, and C++ findings in a single place, cross-language issues included, with no context switching required.

Read our earlier work on pitfalls in multi-language software projects and analyzing multi-language software projects with Axivion.

Where Rust Meets C++ is Where Things Break

FFI boundaries between Rust and C/C++ are where Rust's safety guarantees stop and human error takes over. They're also a blind spot for tools that only look at one language at a time, file by file or function by function.
Axivion's architecture verification lets teams set rules for how Rust and legacy components are allowed to interact so these high-risk boundaries are visible and under control before anything ships.

FFI in Practice. What Clippy Misses, What Axivion Catches.

The Scenario: Rust calling C

A hardware control unit has a C communication interface. A new Rust module binds to it via FFI and calls send_command to dispatch HWCommand structs to the device.

C side (the exported interface)

// exports.h
#pragma pack(push, 1)
typedef struct {
    short id;
    int   flags;
    double value;
} HWCommand;
#pragma pack(pop)

void send_command(HWCommand cmd);
#pragma pack(push, 1) removes padding between fields. The struct is 14 bytes on the C side.

Rust side (the FFI binding)

// main.rs
#[repr(C)]         // correct intent — but missing `packed`
struct HwCommand {
    id:    i16,
    flags: i32,
    value: f64,
}

extern "C" {
    fn send_command(cmd: HwCommand);
}

fn main() {
    let cmd = HwCommand { id: 1, flags: 1, value: 3.14 };
    unsafe { send_command(cmd); }
}
#[repr(C)] preserves C-compatible field ordering but applies natural alignment: 2 bytes of padding are inserted after id to align flags on a 4-byte boundary. The Rust struct is 16 bytes.

What happens at runtime

The device receives garbage. flags and value are read from the wrong byte offsets. The output:

Received Command - id: 1, flags: 65536, value: 0.000000

instead of the expected:

Received Command - id: 1, flags: 1, value: 3.140000

What Clippy sees

Nothing. Clippy operates entirely within the Rust compilation unit. It correctly validates #[repr(C)] usage, checks for unsafe blocks, and flags common Rust mistakes — but it has no visibility into the C header or the #pragma pack directive on the other side of the boundary. From Clippy's perspective, the binding is well-formed.

What Axivion catches

Axivion analyzes both language sides simultaneously. Its Rust-CheckExternSignatures rule compares the Rust extern "C" declaration against the actual exported C symbol and reports:

Import signature does not match export signature Parameter type differs — size differs: 16 vs. 14

The fix is one line:
#[repr(C, packed)]
struct HwCommand { ... }

Why this matters

This class of bug — a layout mismatch at the FFI boundary — cannot be caught by any single-language tool, no matter how thorough. The Rust compiler accepts the binding. The C compiler exports the symbol. Only a tool that holds both language models at the same time can see that the contract between them is broken. That is exactly what Axivion's cross-language analysis provides.

The same principle applies to C# P/Invoke, Python ctypes, or any other FFI mechanism: the individual compiler sees half the picture; Axivion sees the whole system.

Clippy is Step One - Axivion is Step Two

Almost every Rust project already runs Clippy, and that's the right place to start. It enforces idiomatic code, catches common mistakes, and belongs in every CI pipeline.

But Clippy works at the file and function level. It doesn't know anything about your system's architecture, can't show you how code quality is trending over time across a large team, and wasn't built for the compliance and audit demands of safety-critical work.

Axivion picks up where Clippy leaves off while adding the architectural integrity and long-term quality governance that safety-critical and enterprise projects need.

So what does that mean?

Keep Clippy in your pipeline and add Axivion on top.

Keep New Rust Code from Going the Way of the Old C++

Technical debt is cheap to prevent and expensive to fix later.

Teams adopting Rust get a rare chance to start with a clean codebase instead of inheriting the same slow erosion that's already worn down the C/C++ system next to it.

Axivion's delta analysis lets you focus on newly introduced issues, so you can hold new Rust code to a high standard from the first commit without arguing about historical findings on every review.

Pure Rust projects are still rare today, and almost none of them are in production. Going fully Rust in regulated environments will mean redoing certification work. For the foreseeable future, most teams will be living in mixed C/C++/Rust territory, and that's the case Axivion is built for.

As more of the codebase moves to Rust, including the scenarios where AI helps translate it, that AI-generated code needs the same checks human-written code gets.

Whatever your language mix looks like today, and whatever it looks like a few years from now, one tool can cover it.

Learn more about the Axivion Suite and its static code analysis and architecture verification features.