Reserved WASM exported function names

Developers
1

What?

The IC is going to enforce that exported function names must not start with the canister_ prefix except for those explicitly allowed by the Interface Specification (Internet Computer Loading).

Canister developers need to make sure they don’t deploy new canister modules exporting functions with reserved names in the future.

Why?

Exported function names starting with the canister_ prefix and not explicitly allowed by the Interface Specification are reserved so that the IC might introduce such names for new IC features (as was the case for canister_composite_query recently) without breaking existing canisters.

How?

The IC rejects canister modules exporting functions with reserved names during canister module validation. For new canister modules deployed onto the IC, the validation is performed as part of the install_code management canister call.

The change is implemented by this MR: Merge branch 'mraszyk/reject-reserved-exports' into 'master' · dfinity/ic@e4ff4a5 · GitHub.

According to the production logs, existing canisters are not affected by this change. After rolling out the change on mainnet, the IC will reject new canister modules exporting functions with reserved names.

3 Likes
2

Could this be added as a lint to ic_cdk so that this is flagged as an error automatically by a language server like Rust analyzer? Maybe for functions annotated with the ic_cdk::query or ic_cdk::update attribute?

3

If you are using the query and update attributes from ic_cdk, it automatically complies with this requirement. The function name can start with canister_ prefix just fine. It only forbids the exported function name, which starts with either canister_update or canister_query. It only affects CDK authors who are exporting more functions than allowed in the interface spec.

1 Like
4

Thank you for the clarification! Then the question is if it’d be possible to make ic_cdk also forbid all exported function names which start with canister_ and are not allowed by the spec?

1 Like
5

ic-cdk has no control over what #[export_name] the user writes; it is not possible to make such a lint. However, a user using ic-cdk has no reason to use #[export_name] either. It should in general be a non-issue.