dbc/issue-sg-validation.md

Validate SG_ signal definitions and report malformed or unsupported syntax

Description

Following strict validation of BO_ frame definitions, add equivalent validation for SG_ signal definitions. Currently, some malformed statements are accepted silently, and unsupported syntax can produce incorrect decoding.

Examples of current behavior:

• @2+ is interpreted as Motorola instead of being rejected.
• Numeric fields containing suffixes, such as 0junk or 1junk, are partially parsed and accepted.
• SG_ Value m1 : ... is treated as an ordinary signal named Value m1, without multiplexing conditions.
• A statement containing a tab after SG_ is silently skipped.

Scope

• Validate statement structure and require a nonempty signal name without whitespace.
• Accept spaces and tabs between syntax elements.
• Parse numeric fields completely, rejecting overflow and trailing characters; preserve support for fractional values and scientific notation in physical parameters.
• Accept only byte order @0 or @1 and signedness + or -.
• Require signal lengths within 1..64 bits.
• Validate that the signal fits within the frame's declared payload length, using the appropriate Intel or Motorola bit traversal.
• Reject NaN and infinite values for factor, offset, minimum, and maximum; require minimum <= maximum.
• Explicitly reject multiplexing markers M, mN, and their combinations until multiplexing is implemented.
• Preserve the error format path:line: description.

Acceptance criteria

• Existing valid signal definitions continue to parse successfully.
• Malformed and unsupported definitions stop parsing with a clear error.
• Regression tests cover the cases above, numeric boundaries, and Intel/Motorola payload boundaries.
• Existing parser and decoder tests pass.
• README documents the new validation rules and limitations.

Out of scope

Duplicate detection, multiplexing support, and VAL_ support remain separate tasks.

Suggested branch

codex/validate-sg-definitions