Comment by SpaceNugget

As a quick and kind of oversimplified example of what zero copy means, imagine you read the following json string from a file/the network/whatever:

    json = '{"user":"nugget"}' // from somewhere

A simple way to extract json["user"] to a new variable would be to copy the bytes. In pythony/c pseudo code

    let user = allocate_string(6 characters)
    for i in range(0, 6)
      user[i] = json["user"][i]
    // user is now the string "nugget"

instead, a zero copy strategy would be to create a string pointer to the address of json offset by 9, and with a length of 6.

    {"user":"nugget"}
             ^     ]end

The reason this can be tricky in C is that when you call free(json), since user is a pointer to the same string that was json, you have effectively done free(user) as well.

So if you use user after calling free(json), You have written a classic _memory safety_ bug called a "use after free" or UAF. Search around a bit for the insane number of use after free bugs there have been in popular software and the havoc they have wreaked.

In rust, when you create a variable referencing the memory of another (user pointing into json) it keeps track of that (as a "borrow", so that's what the borrow checker does if you have read about that) and won't compile if json is freed while you still have access to user. That's the main memory safety issue involved with zero-copy deserialization techniques.