# Limitations
This document describes what synta-codegen does not support, and where applicable
provides workarounds.
---
## ASN.1 syntax not parsed
The following constructs cause a parse error if they appear in an input file.
### Multiple modules per file
synta-codegen accepts exactly one module per input file. A file containing two or
more `MODULE DEFINITIONS ... END` blocks will fail to parse after the first `END`
is encountered.
**Workaround**: split multi-module files into one file per module before passing
them to the tool. This is the recommended practice for ASN.1 schemas regardless.
### Parameterized types
```asn1
Container { T } ::= SEQUENCE { item T }
```
The braced parameter list is not parsed.
**Workaround**: expand parameterized types manually into concrete definitions.
### Information object classes (CLASS / WITH SYNTAX)
```asn1
CONTENT-TYPE ::= CLASS {
&id OBJECT IDENTIFIER UNIQUE,
&Type
} WITH SYNTAX { &Type IDENTIFIED BY &id }
```
Neither `CLASS` nor `WITH SYNTAX` are parsed.
### Object set assignments
```asn1
SupportedTypes CONTENT-TYPE ::= { ... }
```
Not parsed. Behavior: parse error.
### INSTANCE OF
Not parsed. Behavior: parse error.
---
## Constructs parsed but not code-generated
The following constructs are parsed and recorded in the AST but produce no output
in the generated code. They do not cause errors.
### Table constraints (ComponentRelation)
The surrounding type definition is still emitted. Only the constraint annotation
is dropped.
### User-defined constraints (CONSTRAINED BY)
Silently dropped from generated code.
### PermittedAlphabet constraints (FROM) -- C backend
The Rust backend validates permitted alphabets in the `new()` constructor. The C
backend does not emit alphabet validation; the constraint is dropped for C output.
### Pattern constraints (PATTERN) -- C backend
Rust output optionally validates patterns (enable `regex` feature). The C backend
drops PATTERN constraints from generated code.
### ContainedSubtype (CONTAINING) -- C backend
Rust output optionally validates CONTAINING constraints (enable
`validate_containing` feature). The C backend drops CONTAINING constraints.
### EXPLICIT tag on anonymous inline structural type -- C backend only
An anonymous SEQUENCE, SET, or CHOICE written inline inside an EXPLICIT tag,
without a preceding named type definition, is not fully supported by the C code
generator.
Example (not supported in C output):
```asn1
Wrapper ::= SEQUENCE {
item [0] EXPLICIT SEQUENCE { a INTEGER, b INTEGER }
}
```
The parse succeeds. The Rust backend handles this case correctly. The C backend
emits the outer SEQUENCE but silently omits the EXPLICIT wrapper encoding around
the anonymous inner type.
**Workaround**: extract the inner type to a named definition and reference it by
name.
```asn1
Inner ::= SEQUENCE { a INTEGER, b INTEGER }
Wrapper ::= SEQUENCE {
item [0] EXPLICIT Inner
}
```
---
## Circular dependency detection
Circular module import cycles are detected. Use `--check-imports` to verify a set
of ASN.1 files before generating code:
```bash
synta-codegen a.asn1 b.asn1 --check-imports
```
If a cycle exists, the tool reports it and exits with an error. Code generation
is not attempted.
ASN.1 circular dependencies cannot be resolved automatically. Refactor the schemas
to eliminate the cycle.
---
## PKCS#11 URI Key Loading
The following limitations apply to `BackendPrivateKey::from_pkcs11_uri`.
### NSS backend: `token=` and `object=` are mandatory
The NSS backend uses `PK11_FindSlotByName` to locate the token slot and
`PK11_ListPrivKeysInSlot` to search for the key by label. Both calls require a
non-empty `token=` path attribute. A missing or empty `token=` attribute causes
`from_pkcs11_uri` to return an error immediately.
The `object=` path attribute is also mandatory for the NSS backend. Without it,
there is no nickname to pass as the search filter to `PK11_ListPrivKeysInSlot`,
and the call is rejected at load time.
**Workaround:** always include both attributes for NSS:
```
pkcs11:token=<label>;object=<key-label>;type=private?pin-value=<pin>
```
### NSS backend: Ed448 signing not supported
NSS does not expose a public `SEC_OID_ED448_SIGNATURE` constant in releases
up to NSS 3.121. Signing with Ed448 keys loaded from a PKCS#11 token via the
NSS backend is therefore not supported. Attempting to do so returns a
`PrivateKeyError` at signing time.
**Workaround:** use the OpenSSL backend (`--features openssl`) if Ed448 HSM
signing is required.
### OpenSSL backend: `pkcs11-provider` must be pre-configured
The OpenSSL backend passes the URI directly to `OSSL_STORE_open_ex` with the
process-default `OSSL_LIB_CTX`. The `pkcs11-provider` must already be
registered in the OpenSSL configuration (via `OPENSSL_CONF` pointing to an
`openssl.cnf` that loads the provider) before any call to `from_pkcs11_uri`.
Synta does not load providers automatically.
### HSM-backed keys cannot be serialised
`BackendPrivateKey::to_pem` and `BackendPrivateKey::to_der` (which return
PKCS#8 bytes) are always empty for keys loaded via `from_pkcs11_uri`. Do not
attempt to round-trip an HSM-backed key through PKCS#8 serialisation; the
output will be an empty buffer.
### Only private keys are loaded from PKCS#11 URIs
`BackendPrivateKey::from_pkcs11_uri` loads only private-key objects
(`CKA_CLASS = CKO_PRIVATE_KEY`). Certificate and public-key objects in the
same token are not loaded by this function.
---
## Out of scope
The following are intentionally not generated by synta-codegen.
### BER/CER encoding logic
The synta library's derive macros handle BER/DER/CER encoding at compile time.
synta-codegen generates type definitions and struct layouts; it does not inline
encoding logic.
### Serde derive attributes
Not generated. If Serde integration is needed, add it to the generated types
manually or through a wrapper crate.
### Additional trait implementations
synta-codegen derives `Debug`, `Clone`, and `PartialEq` on generated types. Other
traits (Hash, Ord, Display, etc.) must be added manually.
### Information object class semantics
Table constraints are parsed (see above) but the code generator does not model
or enforce information object class semantics.