How to serialize JSON in no_std library

Hello everyone.

I'm stick in a weird situation.
I'm writing a library for WASM target. As result, I have to use no_std to make it compile. It worked like a charm until I realized that I need JSON serialization. And here be dragons: there is no crate that could to it. Sounds weird "well, just take serde!". Well, it doesn't work.

The reason is that serde itself does support no_std, but serde_json doesn't. Here is direct quote:

std feature should be removed from the crate (to not confuse people that it supports some kind of no_std)

Okay. They propose an alternative - serde-json-core. Trying to compile - fail. Going to the docs - hmm, what they say?

This is explicitly out of scope

  • Anything that involves dynamic memory allocation
    • Like the dynamic Value type

Great. You can serialize JSON, but only types of known length. Want to serialize something like:

struct Person {
   first_name: String,
   second_name: String,
   additional_data: Vec<u8>
}

Well, you can't.

In a nutshell: the problem is that there is curently no crate that works with alloc feature, but without std one. It's exactly the situation with wasm target - you can alloc, but you don't have std library.

And i'm currently stuck here. Maybe I should bring alloc support into serde-json-core crate, but it's not an easy task to me. And I wonder if there is already something that could help.

Thank you for reading.

3 Likes

Why do you need no_std for wasm?

Because i use target that doesn't support std. In my case it's WASM-enabled ethereum virtual machine.

I started to hack serde-json-core, please see link https://github.com/Pzixel/serde-json-core/tree/feature/alloc .
It seems that it already work, but I'd like to fix all unreachable issues. It doesn't support f64 deserialization, what a shame.

Just tried to build a crate for it.
It does not require std, but it still require alloc, and need an allocator

https://crates.io/crates/rjson

The aim is to be minimal and portable, just like cjson, but even further.