Testability Variable-Length Payloads

Testability Variable-Length Payloads#

Scope#

Methods 16, 19, 20, 23, 87, service 65280 / 0xFF00, interface version 1. The full Testability catalog describes all 23 methods and the event. The parser consequences below follow the compiled CGW Java implementation, not a guarantee of exposure or identical behavior in every deployed build.

Selected Codec Bindings#

Merged classes contain unrelated methods. Only the selected typed overload defines a DTO’s wire layout. In particular, serializers in b.a.a.b.c/d/e/f/g do not define their Testability parser layouts, and parsers in b.a.c.b.b/c/d/e/f do not define their Testability serializer layouts.

Method	Request serialize / parse	Response serialize / parse	Nested selected helpers
16 echoInverseDynamicArray	`b.a.c.c.a.b.u` / `b.a.c.c.a.b.t`	`b.a.c.c.a.c.o` / `b.a.c.c.a.c.n`	Parse `b.a.a.b.f` with `b.a.c.a.e`; encode `b.a.c.b.e`
19 echoComplexDynamicArray	`b.a.c.c.a.b.o` / `b.a.c.c.a.b.n`	`b.a.c.c.a.c.i` / `b.a.c.c.a.c.h`	Parse `b.a.a.b.d` with `b.a.c.a.c`; encode `b.a.c.b.c`
20 echoUTF8String	`b.a.c.c.a.b.ae` / `b.a.c.c.a.b.ad`	`b.a.c.c.a.c.Y` / `b.a.c.c.a.c.X`	`org.a.b.b.e.c` string overloads with width 1 and `someip.e.f.b`
23 echoComplexStruct	`b.a.c.c.a.b.r` / `b.a.c.c.a.b.q`	`b.a.c.c.a.c.l` / `b.a.c.c.a.c.k`	Parse `b.a.a.b.e` with `b.a.c.a.d`; encode `b.a.c.b.d`
87 echoLargeDataArray	`b.a.c.c.a.b.A` / `b.a.c.c.a.b.z`	`b.a.c.c.a.c.u` / `b.a.c.c.a.c.t`	Parse `b.a.a.b.c` with `b.a.c.a.b`; encode `b.a.c.b.b`

Both complex-array parsers call the b.a.c.a.f overload in b.a.a.b.g. Both encoders use the b.a.c.a.f overload in b.a.c.b.f. Dispatcher b.a.c.c.a.d selects these codecs. Manager someip.d.e reverses method 16’s element order and echoes the other four values, rather than returning original bytes.

Canonical Layouts#

u8 and u16be are unsigned integers; concatenation is unpadded. Every length counts encoded body bytes excluding its own prefix, not items or Unicode characters. T = u8 a || u16be b is exactly 3 bytes. Strings use UTF-8 with no BOM or terminator (someip.e.f.b). All multibyte integers are big-endian.

Method	Canonical request and success-response layout	Canonical encoded sizes, excluding transport
16	`u8 L	L * u8`; response reverses items
19	`u8 L	n * T`, L=3n
20	`u8 B	B UTF-8 bytes`
23	`u8 a	u8 B
87	`u16be L	n * T`, L=3n

For 23 the exact field order is a, b, c, with no outer struct-length prefix. The c prefix starts at offset 2+B; total consumption is 3+B+C. Its nominal 104-byte maximum is 1+(1+96)+(1+5), not a parse-time outer bound. String maximum constants are 96 - f.b.d(), with f.b.d()=0. Serialization checks this maximum; getSize does not.

Array capacities and defaults are actual backing arrays and counters in b.a.c.a.e, b.a.c.a.c, and b.a.c.a.b, not consequences of prefix widths. Setters write the indexed element before extending logical count. Overflow is a Java array bounds exception, not early count-prefix validation. These capacities are not transport message-size limits.

Boundary Behavior#

Prefix, Declared End, And Full End#

There are three distinct boundaries:

Prefix readability. Array prefix helpers receive byArray.length, even when a narrower n3 helper end is passed. The helper reads the prefix and returns (L,width), without checking body fit. String prefix reads instead use the passed end. At the top dispatcher both ends are the full payload length; the distinction matters only to narrower helper calls, not a separate request path.
Declared array end. The loop tests consumedBody < L. It never passes start+L as an element end and never checks equality or divisibility.
Full primitive/string end. Elements use incoming n3, the full payload length on these top-level paths. Struct parsing reads 1 then 2 bytes. Primitive readers reject underflow against n3; string body-fit checking precedes Java String construction. An inconsistent L does not itself permit a read beyond the actual Java byte array.

The following payload fragments illustrate consequences of these codec rules:

Method / payload fragment	Parser consumption and implied result	Stage consequence
16: `02 01 02`	Consumes 3; response `02 02 01`	Successful reversal
19: `03 01 02 03`	Consumes 4; response unchanged	One valid T, not three items
87: `00 03 01 02 03`	Consumes 5; response unchanged	Two-byte byte-length prefix
19: `01 01 02 03`	Declares 1 body byte but consumes 3 body bytes, 4 total; response `03 01 02 03`	Accepted then canonicalized, not rejected for non-multiple-of-3
87: `00 01 01 02 03`	Consumes 5; response `00 03 01 02 03`	Same overshoot with two-byte prefix
19: `01 01`	Prefix and first byte exist, but u16 does not	Parse exception -> MALFORMED_MESSAGE 9
87: `00`	Missing second prefix byte	Parse exception -> MALFORMED_MESSAGE 9
20: `01`	Prefix exists, body absent	Parse exception -> MALFORMED_MESSAGE 9
23: `07 01 41 01 02`	a=7, b=”A”, c=[2]; consumes 5	Success, exact field order
16: `00 55`	Consumes 1, ignores remaining `55`; response `00`	Dispatcher does not demand full consumption

Overshoot is past the declared subrange, not past full payload memory. Complex bodies consume 3*ceil(L/3) if enough bytes and capacity exist; L=0 runs no iterations. Prefixes requiring more than capacity fail when the setter is reached; insufficient bytes can fail first. Capacity is exceeded at 6 scalar items, 6 small structs, or 8192 large structs (24578 bytes including prefix).

Zero Lengths And Null#

Method 16 00 -> empty array, success 00; method 87 00 00 -> empty array, success 00 00; method 20 00 -> empty string, success 00; method 23 00 00 00 -> a=0,b=””,c=[], success unchanged. Missing prefixes are not zero prefixes.

Method 19 00 is parse-success but response-failure. Its request DTO constructs a complex array whose logical count starts at 1 with a null reference. No loop iteration resets the count. The manager echoes that object. Response size calculation iterates the logical count and calls struct getSize on null, which rejects the invalid type. Failure occurs during response getSize, within the serialization catch and before response allocation/serialize, yielding NOT_OK 1. Direct struct serialization also rejects null.

UTF-8 Acceptance And Re-encoding#

The decoder accepts the full unsigned one-byte length range when bytes exist; it has no 96-byte check. 97…255 ASCII bytes parse successfully, but their echo exceeds 96 and fails response serialization with NOT_OK 1, not parse MALFORMED_MESSAGE 9. The same applies to field b in method 23.

The limit counts encoded bytes: 48 copies of U+00E9 encode to 96 bytes; 49 need 98 and fail canonical encoding. String.getBytes(charset) supplies encoded length, not Java character count. The primitive copies the body before its nominal-maximum check; failure does not produce a successful response.

The decoder constructs new String(bytes,offset,length,"UTF-8") rather than a reporting CharsetDecoder. The isolated invalid byte in method-20 01 80 becomes U+FFFD and re-encodes as 03 ef bf bd, changing prefix and body. Replacement grouping for arbitrary malformed sequences depends on Java’s decoder. Echoes are therefore not necessarily byte-preserving, and replacement can push output above the encoder maximum.

Error Stages#

Dispatcher b.a.c.c.a.d ignores the request parser’s returned consumed length. Any caught parsing exception, including backing-array RuntimeException, maps to MALFORMED_MESSAGE 9. Manager RuntimeException maps separately to NOT_OK 1. Response getSize/allocation/serialize exceptions also map to NOT_OK 1. These stage mappings do not specify handling of uncaught JVM Errors, transport routing, logging failures or deployment-specific allocation limits.

Parser characteristic	Consequence
Non-multiple-of-3 array byte lengths need not end on an item boundary (19/87)	Consumes available bytes beyond declared body and emits a canonical prefix; not an out-of-full-payload read
Top dispatcher ignores consumed length (all five)	Valid leading data plus extra bytes is accepted; successful response need not preserve trailing bytes
Decoder permits 97…255 UTF-8 body bytes, encoder maximum is 96 (20/23)	Parse-success can become response NOT_OK 1 rather than MALFORMED_MESSAGE 9
Zero-body small complex array retains null/default count 1 (19)	Response getSize fails with NOT_OK 1; no valid empty echo
Replacement decoding rather than strict UTF-8 validation (20/23)	Non-byte-preserving echo, potentially larger encoded output
Capacity enforced by indexed writes rather than early prefix validation (16/19/23/87)	Excess elements with sufficient body yield caught parse failure 9, not native memory corruption

These protocol-validation consequences do not establish deployment-specific availability, privilege, confidentiality or native memory-safety impact.