I've been examining WebAssembly sandboxing for agent tool isolation in IronClaw, specifically looking at the boundary between legitimate capability restriction and what I'd classify as "undesirable behavior" within a constrained environment. My usual approach involves fuzzing these interfaces to find memory safety issues, even in WASM's linear memory model, but I need to establish a baseline.

To properly assess the attack surface, I need to understand the minimal, viable tool one can compile to WASM and invoke from a host. Most examples are either overly complex or abstract. I'm looking for the absolute simplest, most stripped-down tool that still performs a recognizable function—something that takes an input, performs a trivial computation, and returns an output, exposing the full host-to-guest and guest-to-host calling convention.

For instance, a tool that counts the number of characters in a string provided by the host would be ideal. This forces us to deal with memory pointer passing, which is where many isolation bugs manifest. Here's my starting point in Rust, targeting `wasm32-unknown-unknown`:

```rust
// In a Cargo.toml: [lib] crate-type = ["cdylib"]
use std::ffi::CStr;
use std::os::raw::c_char;

#[no_mangle]
pub extern "C" fn count_chars(ptr: *const c_char) -> u32 {
let c_str: &CStr = unsafe { CStr::from_ptr(ptr) };
let str_slice: &str = c_str.to_str().unwrap();
str_slice.chars().count() as u32
}
```

This exposes the fundamental pattern: the host allocates memory in the WASM instance's linear memory, writes the string, passes a pointer to the guest, and the guest performs the operation. The guest then returns a simple value directly.

My questions are:
1. Is this the canonical minimal example, or are there even simpler constructs that avoid `CStr` and raw pointer handling? I'm aware of the `wasm-bindgen` approach, but that introduces a larger toolchain footprint I'd like to avoid for initial analysis.
2. From a crash analysis perspective, what are the most common pitfalls in this specific pattern when the host runtime is, say, `wasmtime` or `wasmedge`? I'm thinking about pointer validation (or lack thereof) before the `unsafe` block.
3. For nano agents, would a tool this simple ever be genuinely useful, or does its simplicity make it a poor benchmark for evaluating real-world sandbox escape research? I'm trying to distinguish between theoretical minimalism and practical baseline for fuzzing.

I intend to take the resulting WASM module and subject it to differential fuzzing against a native version of the same function, comparing outputs for corrupted memory pointers and out-of-bounds reads, but I need to ensure the foundation is correct.