Sign inTry Free

Wasm Application Binary Interfaces (ABIs)

On this page

When a Wasm function is created, you can specify one of the following Application Binary Interfaces (ABIs): Basic or Canonical. The default ABI type is Canonical, unless specified explicitly.

  • Basic: This is the bare-bones Wasm ABI. It supports only 32-bit and 64-bit integers and floating point numbers.

  • Canonical: This ABI type is defined by the Canonical ABI specification (a part of the Interface Types proposal). It is a superset of Basic ABI, and it allows usage of structured and complex interface types.

SingleStore supports both the Basic and Canonical Wasm Application Binary Interfaces (ABIs).

  • Using the Basic ABI, SingleStore supports any language that can compile to Wasm code, if the UDF accepts and returns only numeric data types.

  • Using the Canonical ABI, you can pass and return complex data types from UDF/TVF. SingleStore currently supports the following languages for Canonical ABI:

    • C/C++

    • Rust

Note

The user must ensure that the specified ABI type matches the Wasm module implementation. A mismatch may lead to unexpected results at runtime.

Canonical ABI

The canonical ABI is a proposed part of WASI. To use the canonical ABI, you must specify additional metadata in the form of a WIT IDL string.

The wit-bindgen tool, which generates bindings for the Canonical ABI, declares function and structure names as hyphenated strings. Using hyphenated names for UDFs/TVFs requires them to be enclosed in backticks (`), Hence, all function, parameter, and record field names loaded from the Wasm modules are renamed to use underscores instead of hyphens. For example, consider the the following Wasm UDF specified by the WIT definition:

user-function-name: func() -> string;

To call this Wasm UDF, we use the following syntax:

SELECT user_function_name();

Last modified: March 25, 2025

Was this article helpful?

On this page

Was this article helpful?

Verification instructions

Note: You must install cosign to verify the authenticity of the SingleStore file.

Use the following steps to verify the authenticity of singlestoredb-server, singlestoredb-toolbox, singlestoredb-studio, and singlestore-client SingleStore files that have been downloaded.

You may perform the following steps on any computer that can run cosign, such as the main deployment host of the cluster.

  1. (Optional) Run the following command to view the associated signature files.

    curl undefined

  2. Download the signature file from the SingleStore release server.

    • Option 1: Click the Download Signature button next to the SingleStore file.

    • Option 2: Copy and paste the following URL into the address bar of your browser and save the signature file.

    • Option 3: Run the following command to download the signature file.

      curl -O undefined

  3. After the signature file has been downloaded, run the following command to verify the authenticity of the SingleStore file.

    echo -n undefined |
        cosign verify-blob --certificate-oidc-issuer https://oidc.eks.us-east-1.amazonaws.com/id/CCDCDBA1379A5596AB5B2E46DCA385BC \
          --certificate-identity https://kubernetes.io/namespaces/freya-production/serviceaccounts/job-worker \
          --bundle undefined \
          --new-bundle-format -
    Verified OK