Yes you can?

    // lib.h
    struct SecureString {
      uint8_t *content;
      size_t len;
    }

    bool secure_str_eq(l *SecureString, r *SecureString) {
      // some constant-time algorithm
    }

    SecureString *new_secur_string() {
        struct SecureString *s = malloc(sizeof(struct SecureString));
        // initialize s
        return s;
    }

And then in go, for instance, you would do something like this:

    // #include "lib.h"
    import "C"

    type SecureString struct {
        ptr *C.struct_SecureString
    }

    func NewSecureString() *SecureString {
        return &SecureString {
            ptr: C.new_secure_string(),
        }
    }

    func (s *SecureString) Eq(other SecureString*) bool {
        return C.secure_str_eq(h.ptr, other.ptr)
    }

Ok, now how do you provide a SecureUserCreatedStructuredData type?

Serialize SecureUserCreatedStructuredData into an array of SecureString (or SecureInt, etc).

What if I want my application to be performant? There's no value in c abi compatibility if the code internally costs a serialization round trip all the time. May as well just use rusts ffi at that point, it'll be faster!

Also how do you even operate on a SecureUserCreatedStructuredData that is serialized into a SecureString or SecureBytes?

Does my function that operates on a SecureUserCreatedStructureData take in a SecureString, which is documented as needing to be deserializable to a SecureUserCreatedStructureData? If so, that's just a secure void*, with all the problems void* has, and slower.