# IDL→Rust codegen: the bounded-string length check is emitted without regard to @optional, so it calls .len() on Option<String> and fails to compile (E0624)

[swarm59]

IDL→Rust codegen: the bounded-string length check is emitted without regard to @optional, so it calls .len() on Option<String> and fails to compile (E0624)

Crate: zerodds-idl-rust
Version: 1.0.0-rc.6 (source clone at commit b0033675f5, 2026-07-23)
Component: bounded-string bound check (struct_emit.rs:1269)

Type names in the reproducers below are illustrative reduced cases, not real-world names.

Summary

For a bounded string member the generator emits a length guard before encoding — correct behaviour, and the right choice (reject rather than truncate silently).

When the member is also @optional, the field is emitted as Option<String> but the guard is emitted unchanged, so it calls .len() on the Option rather than on the string inside it. The generated code does not compile:

error[E0624]: method `len` is private

The diagnostic is confusing because Option happens to have a private len() in std, so the error is "private method" rather than "no method named len".

Root cause

crates/idl-rust/src/struct_emit.rs:1269:

"if {value_expr}.len() > {n} {{ return Err(zerodds_cdr::EncodeError::ValueOutOfRange {{ message: \"bounded string length exceeds its IDL bound ({n})\" }}.into()); }} "

value_expr is the field access. The optionality of the member — known at this point, since it determines the emitted field type — is not consulted, so the same guard text is produced for String and for Option<String>.

Reproduction

struct S { @optional string<8> code; };

Codegen succeeds (112 lines). Emitted field and guard:

pub code: ::core::option::Option<String>,
...
if self.code.len() > 8 { return Err(zerodds_cdr::EncodeError::ValueOutOfRange { message: "bounded string length exceeds its IDL bound (8)" }.into()); }

Compiling:

error[E0624]: method `len` is private
  --> src\lib.rs:24:26
   |
24 | ...  if self.code.len() > 8 { return Err(zerodds_cdr::EncodeError::ValueOutOfRange { ...
   |                   ^^^ private method

Control — the same IDL without @optional:

struct S { string<8> code; };

emits the identical guard line and compiles cleanly. That is the point: the guard text is the same in both cases; only the field type differs.

Scale

The guard is emitted at four sites per affected member (the XCDR2 LE/BE and XCDR1 encode paths), so the error count is roughly four times the number of @optional bounded-string members. On a mid-size IDL set we saw tens of errors per generated module from this cause alone.

Impact

Any type with an @optional bounded string or wstring member generates code that does not compile. @optional on other member kinds is unaffected, and non-optional bounded strings are correct.

The same pattern appears at struct_emit.rs:1242 for bounded sequences and at :1263 for bounded wstrings; we have not exercised the @optional variants of those, but by inspection they look to have the same shape.

Suggested fix

Where the member is @optional, guard the inner value rather than the Option — for example emit

if let Some(v) = &self.code { if v.len() > 8 { return Err(...); } }

or apply the existing guard to the unwrapped expression the encode path already derives. The check for the absent case is vacuous and should simply not run.

Worth checking the bounded-sequence and bounded-wstring guards at the same time, since they are built the same way.

We have not attempted a patch against the real codebase, preferring to test the unmodified published artefact. Reproducer available on request.

[SandraK82]

Thank you, @swarm59, for the precise report and the compiler diagnostic. You were exactly right: the generated bound check did not carry the member’s @optional state into the emitted expression, so it called .len() directly on an Option<String> and produced uncompilable Rust.

The direct failure is fixed on main in bd7e592. Bound checks for optional members are now guarded and applied only when a value is present, on both the encode and decode paths.

Your report led us into two substantially broader audits.

First, we found that the decoder side often checked only whether enough bytes remained in the input buffer, but did not enforce the bound declared by the IDL type itself. A well-formed peer could therefore send a value larger than string<N>, wstring<N>, sequence<T, N>, or map<K, V, N> and have it accepted. Decode-side bound enforcement has now been added across the supported generated-code backends, including optional, mutable, union, nested-collection, XCDR1/XCDR2, and array-of-bounded-element paths. The Rust path now reports DecodeError::BoundExceeded, and the other language backends use their corresponding error mechanism.

Second, following the same untrusted-length pattern beyond generated IDL code uncovered a wider allocation-hardening family. Several handwritten network decoders could reserve memory from a wire-supplied length before validating it against the remaining frame or a protocol limit. The follow-up in 927d4af added pre-allocation limits and regression tests across the affected OPC UA, AMQP, MQTT, GIOP/CORBA, recorder, security, and CDR TypeCode paths, including a recursion-depth limit for nested TypeCodes.

Each corrected path has a regression proving that an over-bound or oversized value is rejected cleanly while a valid within-bound value still round-trips. The complete public main build is green:
https://github.com/zero-objects/zero-dds/actions/runs/30556000574

I am closing this discussion as fixed. If an optional bounded member still fails to compile, or if you find another generated decoder that accepts a value beyond its declared IDL bound, please let us know here — we will be very happy to reopen the discussion and investigate further.

Thank you again for a report that ultimately improved not only the original Rust code-generation path, but bound enforcement and untrusted-input handling across a much wider part of the project.